Re: assertion failure 9.3.4

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