| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: assertion failure 9.3.4 |
| Date: | 2014-04-23 00:07:25 |
| Message-ID: | 20140423000725.GJ25695@eldon.alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2014-04-23 00:17:04 | Re: assertion failure 9.3.4 |
| Previous Message | Andrew Dunstan | 2014-04-23 00:07:21 | Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD |