Re: BUG #14150: Attempted to delete invisible tuple

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

In response to


Browse pgsql-bugs by date

  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