agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum 7+ messages / 1 participants [nested] [flat]
* pgsql: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum @ 2026-07-28 09:37 Alexander Korotkov <akorotkov@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Alexander Korotkov @ 2026-07-28 09:37 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Restore vacuum_delay_point() in GIN posting-tree leaf vacuum Commit fd83c83d094 turned the recursive posting-tree cleanup in ginVacuumPostingTreeLeaves() into an iterative sweep that follows the tree's leaf pages via their rightlinks. The recursive version called vacuum_delay_point() while processing the tree, but that call was removed and never re-added to the new loop. As that commit only set out to fix a deadlock, the removal appears to have been unintentional. Consequently the leaf-page sweep of a single posting tree runs with no vacuum_delay_point(), and therefore no CHECK_FOR_INTERRUPTS(). A posting tree stores all the TIDs for one indexed key, so for a frequently occurring key it can span a large number of leaf pages. While such a tree is being vacuumed the operation ignores vacuum_cost_delay and does not respond to query cancellation or statement_timeout; an autovacuum worker likewise cannot be interrupted mid-sweep when another backend requests a conflicting lock. Restore the call, placed after the current page has been unlocked and released so that no buffer content lock is held across a potential delay (cf. 21c27af65fb). The sibling loops in ginbulkdelete() and ginvacuumcleanup() already call vacuum_delay_point() once per page. Author: Paul Kim <mok03127@gmail.com> Co-authored-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Reviewed-by: solai v <solai.cdac@gmail.com> Discussion: https://postgr.es/m/178447127453.110.12276981925360691905%40mail.gmail.com Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/8a045f760f67c8aa72881511add869d3d275a431 Modified Files -------------- src/backend/access/gin/ginvacuum.c | 7 +++++++ 1 file changed, 7 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum @ 2026-07-28 09:37 Alexander Korotkov <akorotkov@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Alexander Korotkov @ 2026-07-28 09:37 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Restore vacuum_delay_point() in GIN posting-tree leaf vacuum Commit fd83c83d094 turned the recursive posting-tree cleanup in ginVacuumPostingTreeLeaves() into an iterative sweep that follows the tree's leaf pages via their rightlinks. The recursive version called vacuum_delay_point() while processing the tree, but that call was removed and never re-added to the new loop. As that commit only set out to fix a deadlock, the removal appears to have been unintentional. Consequently the leaf-page sweep of a single posting tree runs with no vacuum_delay_point(), and therefore no CHECK_FOR_INTERRUPTS(). A posting tree stores all the TIDs for one indexed key, so for a frequently occurring key it can span a large number of leaf pages. While such a tree is being vacuumed the operation ignores vacuum_cost_delay and does not respond to query cancellation or statement_timeout; an autovacuum worker likewise cannot be interrupted mid-sweep when another backend requests a conflicting lock. Restore the call, placed after the current page has been unlocked and released so that no buffer content lock is held across a potential delay (cf. 21c27af65fb). The sibling loops in ginbulkdelete() and ginvacuumcleanup() already call vacuum_delay_point() once per page. Author: Paul Kim <mok03127@gmail.com> Co-authored-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Reviewed-by: solai v <solai.cdac@gmail.com> Discussion: https://postgr.es/m/178447127453.110.12276981925360691905%40mail.gmail.com Backpatch-through: 14 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/70dad584e8371eb8a470d882829ba428a22701d4 Modified Files -------------- src/backend/access/gin/ginvacuum.c | 7 +++++++ 1 file changed, 7 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum @ 2026-07-28 09:37 Alexander Korotkov <akorotkov@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Alexander Korotkov @ 2026-07-28 09:37 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Restore vacuum_delay_point() in GIN posting-tree leaf vacuum Commit fd83c83d094 turned the recursive posting-tree cleanup in ginVacuumPostingTreeLeaves() into an iterative sweep that follows the tree's leaf pages via their rightlinks. The recursive version called vacuum_delay_point() while processing the tree, but that call was removed and never re-added to the new loop. As that commit only set out to fix a deadlock, the removal appears to have been unintentional. Consequently the leaf-page sweep of a single posting tree runs with no vacuum_delay_point(), and therefore no CHECK_FOR_INTERRUPTS(). A posting tree stores all the TIDs for one indexed key, so for a frequently occurring key it can span a large number of leaf pages. While such a tree is being vacuumed the operation ignores vacuum_cost_delay and does not respond to query cancellation or statement_timeout; an autovacuum worker likewise cannot be interrupted mid-sweep when another backend requests a conflicting lock. Restore the call, placed after the current page has been unlocked and released so that no buffer content lock is held across a potential delay (cf. 21c27af65fb). The sibling loops in ginbulkdelete() and ginvacuumcleanup() already call vacuum_delay_point() once per page. Author: Paul Kim <mok03127@gmail.com> Co-authored-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Reviewed-by: solai v <solai.cdac@gmail.com> Discussion: https://postgr.es/m/178447127453.110.12276981925360691905%40mail.gmail.com Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/7becb647da743fc3ca059181fef94419cd8167d6 Modified Files -------------- src/backend/access/gin/ginvacuum.c | 7 +++++++ 1 file changed, 7 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum @ 2026-07-28 09:37 Alexander Korotkov <akorotkov@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Alexander Korotkov @ 2026-07-28 09:37 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Restore vacuum_delay_point() in GIN posting-tree leaf vacuum Commit fd83c83d094 turned the recursive posting-tree cleanup in ginVacuumPostingTreeLeaves() into an iterative sweep that follows the tree's leaf pages via their rightlinks. The recursive version called vacuum_delay_point() while processing the tree, but that call was removed and never re-added to the new loop. As that commit only set out to fix a deadlock, the removal appears to have been unintentional. Consequently the leaf-page sweep of a single posting tree runs with no vacuum_delay_point(), and therefore no CHECK_FOR_INTERRUPTS(). A posting tree stores all the TIDs for one indexed key, so for a frequently occurring key it can span a large number of leaf pages. While such a tree is being vacuumed the operation ignores vacuum_cost_delay and does not respond to query cancellation or statement_timeout; an autovacuum worker likewise cannot be interrupted mid-sweep when another backend requests a conflicting lock. Restore the call, placed after the current page has been unlocked and released so that no buffer content lock is held across a potential delay (cf. 21c27af65fb). The sibling loops in ginbulkdelete() and ginvacuumcleanup() already call vacuum_delay_point() once per page. Author: Paul Kim <mok03127@gmail.com> Co-authored-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Reviewed-by: solai v <solai.cdac@gmail.com> Discussion: https://postgr.es/m/178447127453.110.12276981925360691905%40mail.gmail.com Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ba5e4632959027d34ec0254e1597315c3fea4c1e Modified Files -------------- src/backend/access/gin/ginvacuum.c | 7 +++++++ 1 file changed, 7 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum @ 2026-07-28 09:37 Alexander Korotkov <akorotkov@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Alexander Korotkov @ 2026-07-28 09:37 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Restore vacuum_delay_point() in GIN posting-tree leaf vacuum Commit fd83c83d094 turned the recursive posting-tree cleanup in ginVacuumPostingTreeLeaves() into an iterative sweep that follows the tree's leaf pages via their rightlinks. The recursive version called vacuum_delay_point() while processing the tree, but that call was removed and never re-added to the new loop. As that commit only set out to fix a deadlock, the removal appears to have been unintentional. Consequently the leaf-page sweep of a single posting tree runs with no vacuum_delay_point(), and therefore no CHECK_FOR_INTERRUPTS(). A posting tree stores all the TIDs for one indexed key, so for a frequently occurring key it can span a large number of leaf pages. While such a tree is being vacuumed the operation ignores vacuum_cost_delay and does not respond to query cancellation or statement_timeout; an autovacuum worker likewise cannot be interrupted mid-sweep when another backend requests a conflicting lock. Restore the call, placed after the current page has been unlocked and released so that no buffer content lock is held across a potential delay (cf. 21c27af65fb). The sibling loops in ginbulkdelete() and ginvacuumcleanup() already call vacuum_delay_point() once per page. Author: Paul Kim <mok03127@gmail.com> Co-authored-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Reviewed-by: solai v <solai.cdac@gmail.com> Discussion: https://postgr.es/m/178447127453.110.12276981925360691905%40mail.gmail.com Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/006ac761e5080de9934fde8aac027d8c0ac82048 Modified Files -------------- src/backend/access/gin/ginvacuum.c | 7 +++++++ 1 file changed, 7 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum @ 2026-07-28 09:37 Alexander Korotkov <akorotkov@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Alexander Korotkov @ 2026-07-28 09:37 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Restore vacuum_delay_point() in GIN posting-tree leaf vacuum Commit fd83c83d094 turned the recursive posting-tree cleanup in ginVacuumPostingTreeLeaves() into an iterative sweep that follows the tree's leaf pages via their rightlinks. The recursive version called vacuum_delay_point() while processing the tree, but that call was removed and never re-added to the new loop. As that commit only set out to fix a deadlock, the removal appears to have been unintentional. Consequently the leaf-page sweep of a single posting tree runs with no vacuum_delay_point(), and therefore no CHECK_FOR_INTERRUPTS(). A posting tree stores all the TIDs for one indexed key, so for a frequently occurring key it can span a large number of leaf pages. While such a tree is being vacuumed the operation ignores vacuum_cost_delay and does not respond to query cancellation or statement_timeout; an autovacuum worker likewise cannot be interrupted mid-sweep when another backend requests a conflicting lock. Restore the call, placed after the current page has been unlocked and released so that no buffer content lock is held across a potential delay (cf. 21c27af65fb). The sibling loops in ginbulkdelete() and ginvacuumcleanup() already call vacuum_delay_point() once per page. Author: Paul Kim <mok03127@gmail.com> Co-authored-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Reviewed-by: solai v <solai.cdac@gmail.com> Discussion: https://postgr.es/m/178447127453.110.12276981925360691905%40mail.gmail.com Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/15fd7a3e2eeb6de915cae6ea30f40a8e9100cbfe Modified Files -------------- src/backend/access/gin/ginvacuum.c | 7 +++++++ 1 file changed, 7 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum @ 2026-07-28 16:02 Alexander Korotkov <akorotkov@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Alexander Korotkov @ 2026-07-28 16:02 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Restore vacuum_delay_point() in GIN posting-tree leaf vacuum Commit fd83c83d094 turned the recursive posting-tree cleanup in ginVacuumPostingTreeLeaves() into an iterative sweep that follows the tree's leaf pages via their rightlinks. The recursive version called vacuum_delay_point() while processing the tree, but that call was removed and never re-added to the new loop. As that commit only set out to fix a deadlock, the removal appears to have been unintentional. Consequently the leaf-page sweep of a single posting tree runs with no vacuum_delay_point(), and therefore no CHECK_FOR_INTERRUPTS(). A posting tree stores all the TIDs for one indexed key, so for a frequently occurring key it can span a large number of leaf pages. While such a tree is being vacuumed the operation ignores vacuum_cost_delay and does not respond to query cancellation or statement_timeout; an autovacuum worker likewise cannot be interrupted mid-sweep when another backend requests a conflicting lock. Restore the call, placed after the current page has been unlocked and released so that no buffer content lock is held across a potential delay (cf. 21c27af65fb). The sibling loops in ginbulkdelete() and ginvacuumcleanup() already call vacuum_delay_point() once per page. Author: Paul Kim <mok03127@gmail.com> Co-authored-by: Alexander Korotkov <aekorotkov@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru> Reviewed-by: solai v <solai.cdac@gmail.com> Discussion: https://postgr.es/m/178447127453.110.12276981925360691905%40mail.gmail.com Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/7123abab776859257029bc04f89aab777df5e1d7 Modified Files -------------- src/backend/access/gin/ginvacuum.c | 7 +++++++ 1 file changed, 7 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-07-28 16:02 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-07-28 09:37 pgsql: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum Alexander Korotkov <akorotkov@postgresql.org> 2026-07-28 09:37 pgsql: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum Alexander Korotkov <akorotkov@postgresql.org> 2026-07-28 09:37 pgsql: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum Alexander Korotkov <akorotkov@postgresql.org> 2026-07-28 09:37 pgsql: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum Alexander Korotkov <akorotkov@postgresql.org> 2026-07-28 09:37 pgsql: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum Alexander Korotkov <akorotkov@postgresql.org> 2026-07-28 09:37 pgsql: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum Alexander Korotkov <akorotkov@postgresql.org> 2026-07-28 16:02 pgsql: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum Alexander Korotkov <akorotkov@postgresql.org>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox