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
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 |