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>, Taylor Vesely <tvesely@pivotal.io>
Date: 2020-02-12T00:45:32Z
Lists: pgsql-hackers
Hi, On 2020-02-07 16:40:46 -0800, Andres Freund wrote: > I'm currently fighting with a race I'm observing in about 1/4 of the > runs. [...] > I think the issue here is that determines whether s1 can finish its > check_exclusion_or_unique_constraint() check with one retry is whether > it reaches it does the tuple visibility test before s2's transaction has > actually marked itself as visible (note that ProcArrayEndTransaction is > after RecordTransactionCommit logging the COMMIT above). > > I think the fix is quite easy: Ensure that there *always* will be the > second wait iteration on the transaction (in addition to the already > always existing wait on the speculative token). Which is just adding > s2_begin s2_commit steps. Simple, but took me a few hours to > understand :/. > > I've attached that portion of my changes. Will interrupt scheduled > programming for a bit of exercise now. I've pushed this now. Thanks for the patch, and the review! I additionally restricted the controller_print_speculative_locks step to the current database and made a bunch of debug output more precise. Survived ~150 runs locally. Lets 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