pgsql: Test additional speculative conflict scenarios.
Test additional speculative conflict scenarios.
Previously, the speculative insert tests did not cover the case when a
tuple t is inserted into a table with a unique index on a column but
before it can insert into the index, a concurrent transaction has
inserted a conflicting value into the index and the insertion of tuple t
must be aborted.
The basic permutation is one session successfully inserts into the table
and an associated unique index while a concurrent session successfully
inserts into the table but discovers a conflict before inserting into
the index and must abort the insertion.
Several variants on this include:
- swap which session is successful
- first session insert transaction does not commit, so second session
must wait on a transaction lock
- first session insert does not "complete", so second session must wait
on a speculative insertion lock
Also, refactor the existing TOAST table upsert test to be in the same
spec and reuse the steps.
Author: Melanie Plageman, Ashwin Agrawal, Andres Freund
Reviewed-by: Andres Freund, Taylor Vesely
Discussion: /messages/by-id/CAAKRu_ZRmxy_OEryfY3G8Zp01ouhgw59_-_Cm8n7LzRH5BAvng@mail.gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/43e08419708a938236e76cd50de2db512e1c3a0c
Modified Files
--------------
.../expected/insert-conflict-specconflict.out | 277 +++++++++++++++++----
.../isolation/expected/insert-conflict-toast.out | 15 --
src/test/isolation/isolation_schedule | 1 -
.../specs/insert-conflict-specconflict.spec | 140 +++++++++--
.../isolation/specs/insert-conflict-toast.spec | 51 ----
5 files changed, 356 insertions(+), 128 deletions(-)
On Wed, Feb 12, 2020 at 12:43:09AM +0000, Andres Freund wrote:
Test additional speculative conflict scenarios.
Previously, the speculative insert tests did not cover the case when a
tuple t is inserted into a table with a unique index on a column but
before it can insert into the index, a concurrent transaction has
inserted a conflicting value into the index and the insertion of tuple t
must be aborted.
guaibasaurus is unhappy after this commit:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=guaibasaurus&dt=2020-02-12%2004%3A17%3A03
Here is the culprit diff:
application_namelocktype mode granted
+ transactionid ExclusiveLock t
isolation/insert-conflict-specconflict-s1speculative tokenShareLock f
isolation/insert-conflict-specconflict-s1transactionid ExclusiveLock t
isolation/insert-conflict-specconflict-s2speculative tokenExclusiveLock t
--
MichaelHi,
On 2020-02-12 14:07:17 +0900, Michael Paquier wrote:
On Wed, Feb 12, 2020 at 12:43:09AM +0000, Andres Freund wrote:
Test additional speculative conflict scenarios.
Previously, the speculative insert tests did not cover the case when a
tuple t is inserted into a table with a unique index on a column but
before it can insert into the index, a concurrent transaction has
inserted a conflicting value into the index and the insertion of tuple t
must be aborted.guaibasaurus is unhappy after this commit:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=guaibasaurus&dt=2020-02-12%2004%3A17%3A03Here is the culprit diff:
application_namelocktype mode granted+ transactionid ExclusiveLock t
isolation/insert-conflict-specconflict-s1speculative tokenShareLock f
isolation/insert-conflict-specconflict-s1transactionid ExclusiveLock t
isolation/insert-conflict-specconflict-s2speculative tokenExclusiveLock t
Yea, working on the fix already (just restricting application name to
'isolation/insert-conflict-specconflict-s%').
Greetings,
Andres Freund