pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Don't release index root page pin in ginFindParents(). 6+ messages / 1 participants [nested] [flat]
* pgsql: Don't release index root page pin in ginFindParents(). @ 2023-11-13 16:45 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-13 16:45 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Don't release index root page pin in ginFindParents(). It's clearly stated in the comments that ginFindParents() must keep the pin on the index's root page that's associated with the topmost GinBtreeStack item. However, the code path for the case that the desired downlink has been pushed down to the next index level ignored this proviso, and would release the pin anyway if we were still examining the root level. That led to an assertion failure or "buffer NNNN is not owned by resource owner" error later, when we try to release the pin again at the end of the insertion. This is quite hard to reproduce, since it can only happen if an index root page split occurs concurrently with our own insertion. Thanks to Jeff Janes for finding a test case that triggers it often enough to allow investigation. This has been there since the beginning of GIN, so back-patch to all supported branches. Discussion: https://postgr.es/m/CAMkU=1yCAKtv86dMrD__Ja-7KzjE=uMeKX8y__cx5W-OEWy2ow@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/5c62ecf6ec3c912c85a8292a9ad0daa8c0777088 Modified Files -------------- src/backend/access/gin/ginbtree.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't release index root page pin in ginFindParents(). @ 2023-11-13 16:45 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-13 16:45 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Don't release index root page pin in ginFindParents(). It's clearly stated in the comments that ginFindParents() must keep the pin on the index's root page that's associated with the topmost GinBtreeStack item. However, the code path for the case that the desired downlink has been pushed down to the next index level ignored this proviso, and would release the pin anyway if we were still examining the root level. That led to an assertion failure or "buffer NNNN is not owned by resource owner" error later, when we try to release the pin again at the end of the insertion. This is quite hard to reproduce, since it can only happen if an index root page split occurs concurrently with our own insertion. Thanks to Jeff Janes for finding a test case that triggers it often enough to allow investigation. This has been there since the beginning of GIN, so back-patch to all supported branches. Discussion: https://postgr.es/m/CAMkU=1yCAKtv86dMrD__Ja-7KzjE=uMeKX8y__cx5W-OEWy2ow@mail.gmail.com Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f76b975d5887e7e668862e7068eb09073ec23c63 Modified Files -------------- src/backend/access/gin/ginbtree.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't release index root page pin in ginFindParents(). @ 2023-11-13 16:45 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-13 16:45 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Don't release index root page pin in ginFindParents(). It's clearly stated in the comments that ginFindParents() must keep the pin on the index's root page that's associated with the topmost GinBtreeStack item. However, the code path for the case that the desired downlink has been pushed down to the next index level ignored this proviso, and would release the pin anyway if we were still examining the root level. That led to an assertion failure or "buffer NNNN is not owned by resource owner" error later, when we try to release the pin again at the end of the insertion. This is quite hard to reproduce, since it can only happen if an index root page split occurs concurrently with our own insertion. Thanks to Jeff Janes for finding a test case that triggers it often enough to allow investigation. This has been there since the beginning of GIN, so back-patch to all supported branches. Discussion: https://postgr.es/m/CAMkU=1yCAKtv86dMrD__Ja-7KzjE=uMeKX8y__cx5W-OEWy2ow@mail.gmail.com Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4c73ec604844ad2c0b496e401a339b09edd8ef3e Modified Files -------------- src/backend/access/gin/ginbtree.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't release index root page pin in ginFindParents(). @ 2023-11-13 16:45 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-13 16:45 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Don't release index root page pin in ginFindParents(). It's clearly stated in the comments that ginFindParents() must keep the pin on the index's root page that's associated with the topmost GinBtreeStack item. However, the code path for the case that the desired downlink has been pushed down to the next index level ignored this proviso, and would release the pin anyway if we were still examining the root level. That led to an assertion failure or "buffer NNNN is not owned by resource owner" error later, when we try to release the pin again at the end of the insertion. This is quite hard to reproduce, since it can only happen if an index root page split occurs concurrently with our own insertion. Thanks to Jeff Janes for finding a test case that triggers it often enough to allow investigation. This has been there since the beginning of GIN, so back-patch to all supported branches. Discussion: https://postgr.es/m/CAMkU=1yCAKtv86dMrD__Ja-7KzjE=uMeKX8y__cx5W-OEWy2ow@mail.gmail.com Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d900e74e054816cfa94d99a272e174baa7608716 Modified Files -------------- src/backend/access/gin/ginbtree.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't release index root page pin in ginFindParents(). @ 2023-11-13 16:45 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-13 16:45 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Don't release index root page pin in ginFindParents(). It's clearly stated in the comments that ginFindParents() must keep the pin on the index's root page that's associated with the topmost GinBtreeStack item. However, the code path for the case that the desired downlink has been pushed down to the next index level ignored this proviso, and would release the pin anyway if we were still examining the root level. That led to an assertion failure or "buffer NNNN is not owned by resource owner" error later, when we try to release the pin again at the end of the insertion. This is quite hard to reproduce, since it can only happen if an index root page split occurs concurrently with our own insertion. Thanks to Jeff Janes for finding a test case that triggers it often enough to allow investigation. This has been there since the beginning of GIN, so back-patch to all supported branches. Discussion: https://postgr.es/m/CAMkU=1yCAKtv86dMrD__Ja-7KzjE=uMeKX8y__cx5W-OEWy2ow@mail.gmail.com Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c859d688b18b44d7d0dfb2b3a67d5644d9d8dbf1 Modified Files -------------- src/backend/access/gin/ginbtree.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't release index root page pin in ginFindParents(). @ 2023-11-13 16:45 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-13 16:45 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Don't release index root page pin in ginFindParents(). It's clearly stated in the comments that ginFindParents() must keep the pin on the index's root page that's associated with the topmost GinBtreeStack item. However, the code path for the case that the desired downlink has been pushed down to the next index level ignored this proviso, and would release the pin anyway if we were still examining the root level. That led to an assertion failure or "buffer NNNN is not owned by resource owner" error later, when we try to release the pin again at the end of the insertion. This is quite hard to reproduce, since it can only happen if an index root page split occurs concurrently with our own insertion. Thanks to Jeff Janes for finding a test case that triggers it often enough to allow investigation. This has been there since the beginning of GIN, so back-patch to all supported branches. Discussion: https://postgr.es/m/CAMkU=1yCAKtv86dMrD__Ja-7KzjE=uMeKX8y__cx5W-OEWy2ow@mail.gmail.com Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5a6937ec9d41c5d61b72ce42a927a0d590e79491 Modified Files -------------- src/backend/access/gin/ginbtree.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2023-11-13 16:45 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2023-11-13 16:45 pgsql: Don't release index root page pin in ginFindParents(). Tom Lane <tgl@sss.pgh.pa.us> 2023-11-13 16:45 pgsql: Don't release index root page pin in ginFindParents(). Tom Lane <tgl@sss.pgh.pa.us> 2023-11-13 16:45 pgsql: Don't release index root page pin in ginFindParents(). Tom Lane <tgl@sss.pgh.pa.us> 2023-11-13 16:45 pgsql: Don't release index root page pin in ginFindParents(). Tom Lane <tgl@sss.pgh.pa.us> 2023-11-13 16:45 pgsql: Don't release index root page pin in ginFindParents(). Tom Lane <tgl@sss.pgh.pa.us> 2023-11-13 16:45 pgsql: Don't release index root page pin in ginFindParents(). Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox