On 2014-04-22 14:49:00 -0700, Josh Berkus wrote:
>
> >> In order to encounter this issue, I'd need to have two concurrent
> >> processes update the child records of the same parent record? That is:
> >>
> >> A ---> B1
> >> \---> B2
> >>
> >> ... and the issue should only happen if I update both B1 and B2
> >> concurrently in separate sessions?
> >
> > I don't think that'll trigger it. You need rows that are first key share
> > locked and then updated by the locking transaction. Under
> > concurrency. And the timewindow really is rather small..
>
> Well, currently I have a test which locks A and B1, then updates B1
> (twice, actually), and then updates A. However, since there's a lock on
> A, there's no concurrent updating of B1 and B2. This is based on the
> behavior of the queue where I originally saw the problem, but it doesn't
> reproduce the bug.
>
> I'm thinking I need to just lock B1, update B1, then A, while allowing a
> concurrent session to update B2 and and A. No?
I don't think this gets any easier to reproduce by introducing more than
one relation. Have one session acquire key share locks and then update,
and another one just doing updates.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services