Hi, On 2023-09-30 00:50:11 +0200, Laurenz Albe wrote: > On Fri, 2023-09-29 at 17:45 -0400, Bruce Momjian wrote: > > On Tue, Jan 17, 2023 at 12:18:28PM -0500, Arul Ajmani wrote: > > > I'm trying to better understand the following barging behaviour with > > > SHARED > > > locks. > > ... > > > Given there is a transaction waiting to acquire a FOR UPDATE lock, I was > > > surprised to see the second FOR SHARE transaction return immediately > > > instead of > > > waiting. I have two questions: > > > > > > 1) Could this barging behaviour potentially starve out the transaction > > > waiting > > > to acquire the FOR UPDATE lock, if there is a continuous queue of > > > transactions > > > that acquire a FOR SHARE lock briefly? > > > > Yes, see below. > > > > > 2) Assuming this is by design, I couldn't find (in code) where this > > > explicit > > > policy choice is made. I was looking around LockAcquireExtended, but it > > > seems > > > like the decision is made above this layer. Could someone more familiar > > > with > > > this code point me at the right place? > > > > I know this from January, but I do have an answer. [...] > > You answer the question where this is implemented. But the more important > question > is whether this is intentional. This code was added by 0ac5ad5134f > (introducing > FOR KEY SHARE and FOR NO KEY UPDATE). My feeling is that it is not > intentional that > a continuous stream of share row locks can starve out an exclusive row lock, > since > PostgreSQL behaves differently with other locks. > > On the other hand, if nobody has complained about it in these ten years, > perhaps > it is just fine the way it is, if by design or not.
I'd be very hesitant to change the behaviour at this point - the likelihood of existing workloads slowing down substantially, or even breaking due to an additional source of deadlocks, seems substantial. Greetings, Andres Freund
