Adding a test for speculative insert abort case

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Adding a test for speculative insert abort case
Date: 2019-05-01 00:15:55
Message-ID: CAAKRu_a7hbyrk=wveHYhr4LbcRnRCG=yPUVoQYB9YO1CdUBE9Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Today, while poking around the table_complete_speculative code which Ashwin
mentioned in [1], we were trying to understand when exactly we would
complete a
speculative insert by aborting.

We added a logging message to heapam_tuple_complete_speculative before it
calls
heap_abort_speculative and ran the regression and isolation tests to see
what
test failed so we knew how to exercise this codepath.
No tests failed, so we spent some time trying to understand when 'succeeded'
would be true coming into heap_tuple_complete_speculative.

Eventually, we figured out that if one transaction speculatively inserts a
tuple into a table with a unique index and then pauses before inserting the
value into the index, and while it is paused, another transaction
successfully
inserts a value which would conflict with that value, it would result in an
aborted speculative insertion.

t1(id,val)
unique index t1(id)

s1: insert into t1 values(1, 'someval') on conflict(id) do update set val =
'someotherval';
s1: pause in ExecInsert before calling ExecInsertIndexTuples
s2: insert into t1 values(1, 'someval');
s2: continue

We don't know of a way to add this scenario to the current isolation
framework.

Can anyone think of a good way to put this codepath under test?

- Melanie & Ashwin

[1]
https://www.postgresql.org/message-id/CALfoeitk7-TACwYv3hCw45FNPjkA86RfXg4iQ5kAOPhR%2BF1Y4w%40mail.gmail.com

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-05-01 00:22:23 Re: Adding a test for speculative insert abort case
Previous Message Justin Pryzby 2019-05-01 00:14:04 Re: doc: improve PG 12 to_timestamp()/to_date() wording