pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Make XactLockTableWait() and ConditionalXactLockTableWait() inte 6+ messages / 1 participants [nested] [flat]
* pgsql: Make XactLockTableWait() and ConditionalXactLockTableWait() inte @ 2025-05-30 15:15 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: Fujii Masao @ 2025-05-30 15:15 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make XactLockTableWait() and ConditionalXactLockTableWait() interruptable more. Previously, XactLockTableWait() and ConditionalXactLockTableWait() could enter a non-interruptible loop when they successfully acquired a lock on a transaction but the transaction still appeared to be running. Since this loop continued until the transaction completed, it could result in long, uninterruptible waits. Although this scenario is generally unlikely since XactLockTableWait() and ConditionalXactLockTableWait() can basically acquire a transaction lock only when the transaction is not running, it can occur in a hot standby. In such cases, the transaction may still appear active due to the KnownAssignedXids list, even while no lock on the transaction exists. For example, this situation can happen when creating a logical replication slot on a standby. The cause of the non-interruptible loop was the absence of CHECK_FOR_INTERRUPTS() within it. This commit adds CHECK_FOR_INTERRUPTS() to the loop in both functions, ensuring they can be interrupted safely. Back-patch to all supported branches. Author: Kevin K Biju <kevinkbiju@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAM45KeELdjhS-rGuvN=ZLJ_asvZACucZ9LZWVzH7bGcD12DDwg@mail.gmail.com Backpatch-through: 13 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/961553daf5d6087b175aa98f3031a46a8666cecf Modified Files -------------- src/backend/storage/lmgr/lmgr.c | 6 ++++++ 1 file changed, 6 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Make XactLockTableWait() and ConditionalXactLockTableWait() inte @ 2025-05-30 15:15 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: Fujii Masao @ 2025-05-30 15:15 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make XactLockTableWait() and ConditionalXactLockTableWait() interruptable more. Previously, XactLockTableWait() and ConditionalXactLockTableWait() could enter a non-interruptible loop when they successfully acquired a lock on a transaction but the transaction still appeared to be running. Since this loop continued until the transaction completed, it could result in long, uninterruptible waits. Although this scenario is generally unlikely since XactLockTableWait() and ConditionalXactLockTableWait() can basically acquire a transaction lock only when the transaction is not running, it can occur in a hot standby. In such cases, the transaction may still appear active due to the KnownAssignedXids list, even while no lock on the transaction exists. For example, this situation can happen when creating a logical replication slot on a standby. The cause of the non-interruptible loop was the absence of CHECK_FOR_INTERRUPTS() within it. This commit adds CHECK_FOR_INTERRUPTS() to the loop in both functions, ensuring they can be interrupted safely. Back-patch to all supported branches. Author: Kevin K Biju <kevinkbiju@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAM45KeELdjhS-rGuvN=ZLJ_asvZACucZ9LZWVzH7bGcD12DDwg@mail.gmail.com Backpatch-through: 13 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/24c5ad5be46dcaa1ba573f520cf366939a6cae77 Modified Files -------------- src/backend/storage/lmgr/lmgr.c | 6 ++++++ 1 file changed, 6 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Make XactLockTableWait() and ConditionalXactLockTableWait() inte @ 2025-05-30 15:15 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: Fujii Masao @ 2025-05-30 15:15 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make XactLockTableWait() and ConditionalXactLockTableWait() interruptable more. Previously, XactLockTableWait() and ConditionalXactLockTableWait() could enter a non-interruptible loop when they successfully acquired a lock on a transaction but the transaction still appeared to be running. Since this loop continued until the transaction completed, it could result in long, uninterruptible waits. Although this scenario is generally unlikely since XactLockTableWait() and ConditionalXactLockTableWait() can basically acquire a transaction lock only when the transaction is not running, it can occur in a hot standby. In such cases, the transaction may still appear active due to the KnownAssignedXids list, even while no lock on the transaction exists. For example, this situation can happen when creating a logical replication slot on a standby. The cause of the non-interruptible loop was the absence of CHECK_FOR_INTERRUPTS() within it. This commit adds CHECK_FOR_INTERRUPTS() to the loop in both functions, ensuring they can be interrupted safely. Back-patch to all supported branches. Author: Kevin K Biju <kevinkbiju@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAM45KeELdjhS-rGuvN=ZLJ_asvZACucZ9LZWVzH7bGcD12DDwg@mail.gmail.com Backpatch-through: 13 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/63fa7caa958874fd6539497c5c765d57c03e312c Modified Files -------------- src/backend/storage/lmgr/lmgr.c | 6 ++++++ 1 file changed, 6 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Make XactLockTableWait() and ConditionalXactLockTableWait() inte @ 2025-05-30 15:16 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: Fujii Masao @ 2025-05-30 15:16 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make XactLockTableWait() and ConditionalXactLockTableWait() interruptable more. Previously, XactLockTableWait() and ConditionalXactLockTableWait() could enter a non-interruptible loop when they successfully acquired a lock on a transaction but the transaction still appeared to be running. Since this loop continued until the transaction completed, it could result in long, uninterruptible waits. Although this scenario is generally unlikely since XactLockTableWait() and ConditionalXactLockTableWait() can basically acquire a transaction lock only when the transaction is not running, it can occur in a hot standby. In such cases, the transaction may still appear active due to the KnownAssignedXids list, even while no lock on the transaction exists. For example, this situation can happen when creating a logical replication slot on a standby. The cause of the non-interruptible loop was the absence of CHECK_FOR_INTERRUPTS() within it. This commit adds CHECK_FOR_INTERRUPTS() to the loop in both functions, ensuring they can be interrupted safely. Back-patch to all supported branches. Author: Kevin K Biju <kevinkbiju@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAM45KeELdjhS-rGuvN=ZLJ_asvZACucZ9LZWVzH7bGcD12DDwg@mail.gmail.com Backpatch-through: 13 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/405cca9daa422913a83b3b7678f12e745d9c94a6 Modified Files -------------- src/backend/storage/lmgr/lmgr.c | 6 ++++++ 1 file changed, 6 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Make XactLockTableWait() and ConditionalXactLockTableWait() inte @ 2025-05-30 15:16 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: Fujii Masao @ 2025-05-30 15:16 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make XactLockTableWait() and ConditionalXactLockTableWait() interruptable more. Previously, XactLockTableWait() and ConditionalXactLockTableWait() could enter a non-interruptible loop when they successfully acquired a lock on a transaction but the transaction still appeared to be running. Since this loop continued until the transaction completed, it could result in long, uninterruptible waits. Although this scenario is generally unlikely since XactLockTableWait() and ConditionalXactLockTableWait() can basically acquire a transaction lock only when the transaction is not running, it can occur in a hot standby. In such cases, the transaction may still appear active due to the KnownAssignedXids list, even while no lock on the transaction exists. For example, this situation can happen when creating a logical replication slot on a standby. The cause of the non-interruptible loop was the absence of CHECK_FOR_INTERRUPTS() within it. This commit adds CHECK_FOR_INTERRUPTS() to the loop in both functions, ensuring they can be interrupted safely. Back-patch to all supported branches. Author: Kevin K Biju <kevinkbiju@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAM45KeELdjhS-rGuvN=ZLJ_asvZACucZ9LZWVzH7bGcD12DDwg@mail.gmail.com Backpatch-through: 13 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9130d8eeebad201741417490c805b57879eb2205 Modified Files -------------- src/backend/storage/lmgr/lmgr.c | 6 ++++++ 1 file changed, 6 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Make XactLockTableWait() and ConditionalXactLockTableWait() inte @ 2025-05-30 15:16 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: Fujii Masao @ 2025-05-30 15:16 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Make XactLockTableWait() and ConditionalXactLockTableWait() interruptable more. Previously, XactLockTableWait() and ConditionalXactLockTableWait() could enter a non-interruptible loop when they successfully acquired a lock on a transaction but the transaction still appeared to be running. Since this loop continued until the transaction completed, it could result in long, uninterruptible waits. Although this scenario is generally unlikely since XactLockTableWait() and ConditionalXactLockTableWait() can basically acquire a transaction lock only when the transaction is not running, it can occur in a hot standby. In such cases, the transaction may still appear active due to the KnownAssignedXids list, even while no lock on the transaction exists. For example, this situation can happen when creating a logical replication slot on a standby. The cause of the non-interruptible loop was the absence of CHECK_FOR_INTERRUPTS() within it. This commit adds CHECK_FOR_INTERRUPTS() to the loop in both functions, ensuring they can be interrupted safely. Back-patch to all supported branches. Author: Kevin K Biju <kevinkbiju@gmail.com> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Discussion: https://postgr.es/m/CAM45KeELdjhS-rGuvN=ZLJ_asvZACucZ9LZWVzH7bGcD12DDwg@mail.gmail.com Backpatch-through: 13 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/706344f06fbdc492f1edd97ed2028df5a7559b8b Modified Files -------------- src/backend/storage/lmgr/lmgr.c | 6 ++++++ 1 file changed, 6 insertions(+) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2025-05-30 15:16 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-05-30 15:15 pgsql: Make XactLockTableWait() and ConditionalXactLockTableWait() inte Fujii Masao <fujii@postgresql.org> 2025-05-30 15:15 pgsql: Make XactLockTableWait() and ConditionalXactLockTableWait() inte Fujii Masao <fujii@postgresql.org> 2025-05-30 15:15 pgsql: Make XactLockTableWait() and ConditionalXactLockTableWait() inte Fujii Masao <fujii@postgresql.org> 2025-05-30 15:16 pgsql: Make XactLockTableWait() and ConditionalXactLockTableWait() inte Fujii Masao <fujii@postgresql.org> 2025-05-30 15:16 pgsql: Make XactLockTableWait() and ConditionalXactLockTableWait() inte Fujii Masao <fujii@postgresql.org> 2025-05-30 15:16 pgsql: Make XactLockTableWait() and ConditionalXactLockTableWait() inte Fujii Masao <fujii@postgresql.org>
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