Re: Adding a test for speculative insert abort case
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>, Peter Geoghegan <pg@bowt.ie>
Date: 2019-05-14T19:19:14Z
Lists: pgsql-hackers
Hi, On 2019-05-10 14:40:38 -0700, Andres Freund wrote: > On 2019-05-01 11:41:48 -0700, Andres Freund wrote: > > I'm imagining something like > > > > if (pg_try_advisory_xact_lock(1)) > > pg_advisory_xact_lock(2); > > else > > pg_advisory_xact_lock(1); > > > > in t1_lock_func. If you then make the session something roughly like > > > > s1: pg_advisory_xact_lock(1); > > s1: pg_advisory_xact_lock(2); > > > > s2: upsert t1 <blocking for 1> > > s1: pg_advisory_xact_unlock(1); > > s2: <continuing> > > s2: <blocking for 2> > > s1: insert into t1 values(1, 'someval'); > > s1: pg_advisory_xact_unlock(2); > > s2: <continuing> > > s2: spec-conflict > > Needed to be slightly more complicated than that, but not that much. See > the attached test. What do you think? > > I think we should apply something like this (minus the WARNING, of > course). It's a bit complicated, but it seems worth covering this > special case. And pushed. Let's see what the buildfarm says. Regards, Andres
Commits
-
Test additional speculative conflict scenarios.
- 43e08419708a 13.0 landed
-
Add isolation test for INSERT ON CONFLICT speculative insertion failure.
- 0491a51fdd4e 9.6.14 landed
- 04595960a0a7 10.9 landed
- 05cf41973157 11.4 landed
- 08e2edc0767a 12.0 landed