29.06.2016, 08:13, Michael Paquier kirjoitti:
> On Wed, Jun 29, 2016 at 8:40 AM, Peter Geoghegan <pg@heroku.com> wrote:
>> On Mon, Jun 27, 2016 at 8:28 PM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>>> Could you post it? I'd be interested in seeing that.
>>
>> Attached is a reasonably minimal testcase, showing many "attempted to
>> delete invisible tuple" errors for me quickly and reliably. The
>> shellscript expects to be able to invoke pgbench without any custom
>> arguments, and runs the attach custom pgbench script in an infinite
>> loop. On my laptop, there is a roughly 90% chance that the script's 5
>> second pgbench runs will raise the error at least once.
>
> Thanks! I can see the problem with that. Now let's dig into it...
I ran into this yesterday on 9.5.3 and created a test case before
noticing this thread. My test case just inserts a single
toast-requiring row using ON CONFLICT DO NOTHING and typically fails
immediately:
pgbench -f random.sql -n -T 2 -c 2
random.sql:
-- CREATE TABLE vtest (id INT UNIQUE, blob BYTEA);
TRUNCATE vtest;
INSERT INTO vtest (id, blob) VALUES (1, encrypt(repeat('a',
8192)::bytea, 'x'::bytea, 'aes')) ON CONFLICT DO NOTHING;
ISTM this is caused by toast knowing nothing about speculative
insertion: when two backends have executed a speculative heap_insert
with a conflicting key and the latter one tries to abort after receiving
specConflict there's nothing in tqual.c to say that the toast rows
associated with speculative insertion should be visible to that operation.
/ Oskari
