On Wed, Jul 6, 2016 at 3:30 AM, Oskari Saarenmaa <os@aiven.io> wrote:
>> 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.
I don't really understand your explanation of what this patch does.
Obviously heap_abort_speculative() often has no apparent problem with
any of this; this bug involves a relatively rare race condition
scenario where there *is* a problem. We didn't simply neglect to make
heap_abort_speculative() consider TOAST at all, though.
My sense is that the problem occurs before Postgres throw this
"attempted to delete invisible tuple", and that a better fix is one
that prevents that condition from occurring in the first place
according to the extant visibility rules for
HeapTupleSatisfiesUpdate(). I'm not sure that your fix has not merely
masked the issue.
--
Peter Geoghegan