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: Ashwin Agrawal <aagrawal@pivotal.io>, Pg Hackers <pgsql-hackers@postgresql.org>, Peter Geoghegan <pg@bowt.ie>
Date: 2019-05-16T21:03:41Z
Lists: pgsql-hackers
Hi, On 2019-05-16 13:59:47 -0700, Melanie Plageman wrote: > On Wed, May 15, 2019 at 10:32 PM Ashwin Agrawal <aagrawal@pivotal.io> wrote: > > > > > The second index would help to hold the session after inserting the tuple > > in unique index but before completing the speculative insert. Hence, helps > > to create the condition easily. I believe order of index insertion is > > helping here that unique index is inserted and then non-unique index is > > inserted too. > > > > > Oh, cool. I didn't know that execution order would be guaranteed for which > index > to insert into first. It's not *strictly* speaking *always* well defined. The list of indexes is sorted by the oid of the index - so once created, it's consistent. But when the oid assignment wraps around, it'd be the other way around. But I think it's ok to disregard that - it'll never happen in regression tests run against a new cluster, and you'd have to run tests against an installed cluster for a *LONG* time for a *tiny* window where the wraparound would happen precisely between the creation of the two indexes. Makes sense? I guess we could make that case a tiny bit easier to diagnose in the extremely unlikely case it happens by having a step that outputs SELECT 'index_a'::regclass::int8 < 'index_b'::regclass::int8; Greetings, Andres Freund
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