| From: | shihao zhong <zhong950419(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alex Shapalov <shapalov(at)gmail(dot)com>, Sami Imseih <samimseih(dot)pg(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Subject: | Reset waitStart when a lock wait fails |
| Date: | 2026-09-24 01:30:19 |
| Message-ID: | CAGRkXqQLxZBr-ouVrtaX2utMggi4+TiVMbgH04b_0JLgKryxbA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
Alex and Sami noticed in [1] that RemoveFromWaitQueue() does not clear
PGPROC->waitStart. After lock_timeout, cancel or deadlock the old value
stays until the next lock wait.
It leaks into pg_locks for a short time. The next wait joins the queue
before ProcSleep() stores the new waitStart, and in that window pg_locks
shows the old start time instead of NULL. Backend stopped at ProcSleep()
entry, a few seconds after a lock_timeout:
pid | relation | mode | granted | waitstart
-------+----------+---------------------+---------+-------------------------------
42442 | t | AccessExclusiveLock | f | 2026-09-23
21:01:39.274763-04
With the patch it reads NULL. The patch clears it the same way
ProcWakeup() does, like 70f470314cb did for the grant path. It applies
to 14 and up.
[1]
https://postgr.es/m/CAPrb+Q+XN=sNusXiUeWmMo2H7Qgq3Y4uPekSSLkHcnCyf7GhXg@mail.gmail.com
Thanks,
Shihao
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Reset-waitStart-when-a-lock-wait-fails.patch | application/octet-stream | 1.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shihao zhong | 2026-09-24 01:45:34 | Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten |
| Previous Message | zengxx | 2026-09-24 01:26:46 | 回复: Skip a redundant singleton GROUP BY node |