Re: Reset waitStart when a lock wait fails - Mailing list pgsql-hackers

From shihao zhong
Subject Re: Reset waitStart when a lock wait fails
Date
Msg-id CAGRkXqSvF2PUHCcX4S5WQQLoPmsB_9vHXeYDVp=uROFrVaCZLw@mail.gmail.com
Whole thread
In response to Re: Reset waitStart when a lock wait fails  (Andrew Krylosov <krylosov.andrew@gmail.com>)
Responses Re: Reset waitStart when a lock wait fails
List pgsql-hackers
Hi Andrew,

> 1) I think 0001 is not needed anymore once 0002 is applied. With
> 0002, the waiting backend always clears waitStart itself when the wait
> ends at the end of ProcSleep(), or in LockErrorCleanup().
> RemoveFromWaitQueue() is only called from CheckDeadLock() and
> LockErrorCleanup(), and both paths reach one of these new resets.
>
> Maybe it is simpler to merge 0001 and 0002 into one commit?
> They fix the same problem and would be backpatched together.

Agreed, v3 merges them into one patch. The code is the same as v2.

You are right that the RemoveFromWaitQueue() line is no longer needed.
I kept it so it matches ProcWakeup(), since Chao and Michael wanted the
field cleared there. I'm fine with dropping it if Fujii-san prefers. On
14 to 17 there is a third caller, the early deadlock exit in
ProcSleep(), but it runs before waitStart is set, so your point holds
there too.

> 2) 0001 has "Backpatch-through: 14", but 0002 has no such line.

My mistake. v3 has Backpatch-through: 14.

Thanks,
Shihao
Attachment

pgsql-hackers by date:

Previous
From: Mihail Nikalayeu
Date:
Subject: Re: Support EXCEPT for TABLES IN SCHEMA publications
Next
From: shihao zhong
Date:
Subject: Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes