Thread: 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: https://postgr.es/m/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 -- Michael
Attachment
Hi, 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%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 Yea, working on the fix already (just restricting application name to 'isolation/insert-conflict-specconflict-s%'). Greetings, Andres Freund