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?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com