agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Prevent stale pg_locks.waitstart values 7+ messages / 1 participants [nested] [flat]
* pgsql: Prevent stale pg_locks.waitstart values @ 2026-09-28 05:23 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Fujii Masao @ 2026-09-28 05:23 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Prevent stale pg_locks.waitstart values Previously, pg_locks.waitstart could report the start time of a previous lock wait for a new wait. For a regular backend, this could happen briefly before the new start time was stored. On a standby, the startup process could show the old time throughout the next wait, making it appear to have started earlier than it did. This happened because PGPROC->waitStart could remain set after a previous wait in two cases. First, RemoveFromWaitQueue() did not clear it when a wait was canceled due to a lock timeout, cancellation, or deadlock. Second, even after a successful lock grant, ProcWakeup() could clear it before the waiter stored its new start time. Fix this by clearing waitStart in RemoveFromWaitQueue() when a failed wait is removed, at the end of ProcSleep() to handle writes made after ProcWakeup() cleared it, and in LockErrorCleanup() when an error bypasses the ProcSleep() reset. This prevents pg_locks.waitstart from showing the previous wait's time for a new wait. Backpatch to all supported versions. Author: Shihao Zhong <zhong950419@gmail.com> Reported-by: Alex Shapalov <shapalov@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Andrew Krylosov <krylosov.andrew@gmail.com> Discussion: https://postgr.es/m/CAPrb+Q+XN=sNusXiUeWmMo2H7Qgq3Y4uPekSSLkHcnCyf7GhXg@mail.gmail.com Discussion: https://postgr.es/m/CAGRkXqQLxZBr-ouVrtaX2utMggi4+TiVMbgH04b_0JLgKryxbA@mail.gmail.com Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/5bd2e236e21b0e158dda43c184260b9395ede4f4 Modified Files -------------- src/backend/storage/lmgr/lock.c | 1 + src/backend/storage/lmgr/proc.c | 9 +++++++++ 2 files changed, 10 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Prevent stale pg_locks.waitstart values @ 2026-09-28 05:23 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Fujii Masao @ 2026-09-28 05:23 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Prevent stale pg_locks.waitstart values Previously, pg_locks.waitstart could report the start time of a previous lock wait for a new wait. For a regular backend, this could happen briefly before the new start time was stored. On a standby, the startup process could show the old time throughout the next wait, making it appear to have started earlier than it did. This happened because PGPROC->waitStart could remain set after a previous wait in two cases. First, RemoveFromWaitQueue() did not clear it when a wait was canceled due to a lock timeout, cancellation, or deadlock. Second, even after a successful lock grant, ProcWakeup() could clear it before the waiter stored its new start time. Fix this by clearing waitStart in RemoveFromWaitQueue() when a failed wait is removed, at the end of ProcSleep() to handle writes made after ProcWakeup() cleared it, and in LockErrorCleanup() when an error bypasses the ProcSleep() reset. This prevents pg_locks.waitstart from showing the previous wait's time for a new wait. Backpatch to all supported versions. Author: Shihao Zhong <zhong950419@gmail.com> Reported-by: Alex Shapalov <shapalov@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Andrew Krylosov <krylosov.andrew@gmail.com> Discussion: https://postgr.es/m/CAPrb+Q+XN=sNusXiUeWmMo2H7Qgq3Y4uPekSSLkHcnCyf7GhXg@mail.gmail.com Discussion: https://postgr.es/m/CAGRkXqQLxZBr-ouVrtaX2utMggi4+TiVMbgH04b_0JLgKryxbA@mail.gmail.com Backpatch-through: 14 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/bb356f869fa595db8c2bee4ae4096a64897d7aa7 Modified Files -------------- src/backend/storage/lmgr/lock.c | 1 + src/backend/storage/lmgr/proc.c | 9 +++++++++ 2 files changed, 10 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Prevent stale pg_locks.waitstart values @ 2026-09-28 05:24 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Fujii Masao @ 2026-09-28 05:24 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Prevent stale pg_locks.waitstart values Previously, pg_locks.waitstart could report the start time of a previous lock wait for a new wait. For a regular backend, this could happen briefly before the new start time was stored. On a standby, the startup process could show the old time throughout the next wait, making it appear to have started earlier than it did. This happened because PGPROC->waitStart could remain set after a previous wait in two cases. First, RemoveFromWaitQueue() did not clear it when a wait was canceled due to a lock timeout, cancellation, or deadlock. Second, even after a successful lock grant, ProcWakeup() could clear it before the waiter stored its new start time. Fix this by clearing waitStart in RemoveFromWaitQueue() when a failed wait is removed, at the end of ProcSleep() to handle writes made after ProcWakeup() cleared it, and in LockErrorCleanup() when an error bypasses the ProcSleep() reset. This prevents pg_locks.waitstart from showing the previous wait's time for a new wait. Backpatch to all supported versions. Author: Shihao Zhong <zhong950419@gmail.com> Reported-by: Alex Shapalov <shapalov@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Andrew Krylosov <krylosov.andrew@gmail.com> Discussion: https://postgr.es/m/CAPrb+Q+XN=sNusXiUeWmMo2H7Qgq3Y4uPekSSLkHcnCyf7GhXg@mail.gmail.com Discussion: https://postgr.es/m/CAGRkXqQLxZBr-ouVrtaX2utMggi4+TiVMbgH04b_0JLgKryxbA@mail.gmail.com Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ccffd34399f5cd8266c98f0365b648a80e67727b Modified Files -------------- src/backend/storage/lmgr/lock.c | 1 + src/backend/storage/lmgr/proc.c | 9 +++++++++ 2 files changed, 10 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Prevent stale pg_locks.waitstart values @ 2026-09-28 05:24 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Fujii Masao @ 2026-09-28 05:24 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Prevent stale pg_locks.waitstart values Previously, pg_locks.waitstart could report the start time of a previous lock wait for a new wait. For a regular backend, this could happen briefly before the new start time was stored. On a standby, the startup process could show the old time throughout the next wait, making it appear to have started earlier than it did. This happened because PGPROC->waitStart could remain set after a previous wait in two cases. First, RemoveFromWaitQueue() did not clear it when a wait was canceled due to a lock timeout, cancellation, or deadlock. Second, even after a successful lock grant, ProcWakeup() could clear it before the waiter stored its new start time. Fix this by clearing waitStart in RemoveFromWaitQueue() when a failed wait is removed, at the end of ProcSleep() to handle writes made after ProcWakeup() cleared it, and in LockErrorCleanup() when an error bypasses the ProcSleep() reset. This prevents pg_locks.waitstart from showing the previous wait's time for a new wait. Backpatch to all supported versions. Author: Shihao Zhong <zhong950419@gmail.com> Reported-by: Alex Shapalov <shapalov@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Andrew Krylosov <krylosov.andrew@gmail.com> Discussion: https://postgr.es/m/CAPrb+Q+XN=sNusXiUeWmMo2H7Qgq3Y4uPekSSLkHcnCyf7GhXg@mail.gmail.com Discussion: https://postgr.es/m/CAGRkXqQLxZBr-ouVrtaX2utMggi4+TiVMbgH04b_0JLgKryxbA@mail.gmail.com Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/0165f38d11ec00a0efacccb746c2d1d6309b0f0b Modified Files -------------- src/backend/storage/lmgr/lock.c | 1 + src/backend/storage/lmgr/proc.c | 9 +++++++++ 2 files changed, 10 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Prevent stale pg_locks.waitstart values @ 2026-09-28 05:24 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Fujii Masao @ 2026-09-28 05:24 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Prevent stale pg_locks.waitstart values Previously, pg_locks.waitstart could report the start time of a previous lock wait for a new wait. For a regular backend, this could happen briefly before the new start time was stored. On a standby, the startup process could show the old time throughout the next wait, making it appear to have started earlier than it did. This happened because PGPROC->waitStart could remain set after a previous wait in two cases. First, RemoveFromWaitQueue() did not clear it when a wait was canceled due to a lock timeout, cancellation, or deadlock. Second, even after a successful lock grant, ProcWakeup() could clear it before the waiter stored its new start time. Fix this by clearing waitStart in RemoveFromWaitQueue() when a failed wait is removed, at the end of ProcSleep() to handle writes made after ProcWakeup() cleared it, and in LockErrorCleanup() when an error bypasses the ProcSleep() reset. This prevents pg_locks.waitstart from showing the previous wait's time for a new wait. Backpatch to all supported versions. Author: Shihao Zhong <zhong950419@gmail.com> Reported-by: Alex Shapalov <shapalov@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Andrew Krylosov <krylosov.andrew@gmail.com> Discussion: https://postgr.es/m/CAPrb+Q+XN=sNusXiUeWmMo2H7Qgq3Y4uPekSSLkHcnCyf7GhXg@mail.gmail.com Discussion: https://postgr.es/m/CAGRkXqQLxZBr-ouVrtaX2utMggi4+TiVMbgH04b_0JLgKryxbA@mail.gmail.com Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/6f2f510845c522fc5d57a05cabc492fce3ff23bb Modified Files -------------- src/backend/storage/lmgr/lock.c | 1 + src/backend/storage/lmgr/proc.c | 9 +++++++++ 2 files changed, 10 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Prevent stale pg_locks.waitstart values @ 2026-09-28 05:24 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Fujii Masao @ 2026-09-28 05:24 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Prevent stale pg_locks.waitstart values Previously, pg_locks.waitstart could report the start time of a previous lock wait for a new wait. For a regular backend, this could happen briefly before the new start time was stored. On a standby, the startup process could show the old time throughout the next wait, making it appear to have started earlier than it did. This happened because PGPROC->waitStart could remain set after a previous wait in two cases. First, RemoveFromWaitQueue() did not clear it when a wait was canceled due to a lock timeout, cancellation, or deadlock. Second, even after a successful lock grant, ProcWakeup() could clear it before the waiter stored its new start time. Fix this by clearing waitStart in RemoveFromWaitQueue() when a failed wait is removed, at the end of ProcSleep() to handle writes made after ProcWakeup() cleared it, and in LockErrorCleanup() when an error bypasses the ProcSleep() reset. This prevents pg_locks.waitstart from showing the previous wait's time for a new wait. Backpatch to all supported versions. Author: Shihao Zhong <zhong950419@gmail.com> Reported-by: Alex Shapalov <shapalov@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Andrew Krylosov <krylosov.andrew@gmail.com> Discussion: https://postgr.es/m/CAPrb+Q+XN=sNusXiUeWmMo2H7Qgq3Y4uPekSSLkHcnCyf7GhXg@mail.gmail.com Discussion: https://postgr.es/m/CAGRkXqQLxZBr-ouVrtaX2utMggi4+TiVMbgH04b_0JLgKryxbA@mail.gmail.com Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/0ef59b2856794d01b6619dd787de616cc903fa7d Modified Files -------------- src/backend/storage/lmgr/lock.c | 1 + src/backend/storage/lmgr/proc.c | 9 +++++++++ 2 files changed, 10 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Prevent stale pg_locks.waitstart values @ 2026-09-28 05:24 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: Fujii Masao @ 2026-09-28 05:24 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Prevent stale pg_locks.waitstart values Previously, pg_locks.waitstart could report the start time of a previous lock wait for a new wait. For a regular backend, this could happen briefly before the new start time was stored. On a standby, the startup process could show the old time throughout the next wait, making it appear to have started earlier than it did. This happened because PGPROC->waitStart could remain set after a previous wait in two cases. First, RemoveFromWaitQueue() did not clear it when a wait was canceled due to a lock timeout, cancellation, or deadlock. Second, even after a successful lock grant, ProcWakeup() could clear it before the waiter stored its new start time. Fix this by clearing waitStart in RemoveFromWaitQueue() when a failed wait is removed, at the end of ProcSleep() to handle writes made after ProcWakeup() cleared it, and in LockErrorCleanup() when an error bypasses the ProcSleep() reset. This prevents pg_locks.waitstart from showing the previous wait's time for a new wait. Backpatch to all supported versions. Author: Shihao Zhong <zhong950419@gmail.com> Reported-by: Alex Shapalov <shapalov@gmail.com> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Reviewed-by: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Andrew Krylosov <krylosov.andrew@gmail.com> Discussion: https://postgr.es/m/CAPrb+Q+XN=sNusXiUeWmMo2H7Qgq3Y4uPekSSLkHcnCyf7GhXg@mail.gmail.com Discussion: https://postgr.es/m/CAGRkXqQLxZBr-ouVrtaX2utMggi4+TiVMbgH04b_0JLgKryxbA@mail.gmail.com Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/edfa6c8fcbfea8721180276855c893ee8fc56598 Modified Files -------------- src/backend/storage/lmgr/lock.c | 1 + src/backend/storage/lmgr/proc.c | 9 +++++++++ 2 files changed, 10 insertions(+) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-09-28 05:24 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-09-28 05:23 pgsql: Prevent stale pg_locks.waitstart values Fujii Masao <fujii@postgresql.org> 2026-09-28 05:23 pgsql: Prevent stale pg_locks.waitstart values Fujii Masao <fujii@postgresql.org> 2026-09-28 05:24 pgsql: Prevent stale pg_locks.waitstart values Fujii Masao <fujii@postgresql.org> 2026-09-28 05:24 pgsql: Prevent stale pg_locks.waitstart values Fujii Masao <fujii@postgresql.org> 2026-09-28 05:24 pgsql: Prevent stale pg_locks.waitstart values Fujii Masao <fujii@postgresql.org> 2026-09-28 05:24 pgsql: Prevent stale pg_locks.waitstart values Fujii Masao <fujii@postgresql.org> 2026-09-28 05:24 pgsql: Prevent stale pg_locks.waitstart values Fujii Masao <fujii@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