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.
If you want to make it easier to reproduce, you need to insert some pg_usleep() calls in carefully selected spots. As Andres says, the window is small normally. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
