On 2014-04-22 14:40:46 -0700, Josh Berkus wrote:
> On 04/22/2014 02:01 PM, Alvaro Herrera wrote:
> > Some testing later, I think the issue only occurs if we determine that
> > we don't need to wait for the xid/multi to complete, because otherwise
> > the wait itself saves us. (It's easy to cause the problem by adding a
> > breakpoint in heapam.c:3325, i.e. just before re-acquiring the buffer
> > lock, and then having transaction A lock for key share, then transaction
> > B update the tuple which stops at the breakpoint, then transaction A
> > also update the tuple, and finally release transaction B).
>
> So, trying to make my synthetic test work:
>
> 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..
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
