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