From: | Oskari Saarenmaa <os(at)aiven(dot)io> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Peter Tripp <peter(at)chartio(dot)com>, Virendra Negi <virendra(at)idyllic-software(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14150: Attempted to delete invisible tuple |
Date: | 2016-07-06 10:30:57 |
Message-ID: | 62f3793f-13d6-567c-e512-f29d1fd76d00@aiven.io |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
06.07.2016, 09:05, Oskari Saarenmaa kirjoitti:
> 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.
The attached patch against current master allows heap_abort_speculative
to delete toast rows created by the same command which makes the above
test case and "make check" run without failures. Note that I haven't
touched this code before so I don't know how safe my patch is.
/ Oskari
Attachment | Content-Type | Size |
---|---|---|
0001-Delete-current-command-s-TOAST-when-aborting-specula.patch | text/x-patch | 9.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kim Rose Carlsen | 2016-07-06 12:59:30 | SELECT ... FOR UPDATE OF <table> SKIP LOCKED returns can same row when table is filtered on different table than locked |
Previous Message | Timur Luchkin | 2016-07-06 07:47:49 | Re: Too slow "Analyze" for the table with data in Thai language |