agora inbox for pgsql-committers@postgresql.org  
help / 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