On Wed, Aug 17, 2016 at 8:06 PM Andres Freund <andres@anarazel.de> wrote:
> This commit updates the heap_abort_speculative() function which aborts
> the conflicting tuple to use itself, via toast_delete, for deleting
> associated TOAST datums. Like before, the inserted toast rows are not
> marked as being speculative.
I just noticed how crazy this is - not the commit itself
(07ef035129586ca26a713c4cd15e550dfe35e643) but the thing which the
commit message describes as pre-existing behavior. Apparently, even
if the insertion wasn't speculative, you can still abort it just as if
it had been, at least when we're talking about a TOAST table row. Not
that I have a better idea, but are we sure that's the way we want to
go?
This is relevant to my little project to make the TOAST logic reusable
by other AMs, because the comments in tableam.h suggest you can only
complete a speculative insertion if you've previously performed one.
If we allow any AM to be used to implement a TOAST table, then it
needs to be documented that such AMs have to cope with this kind of
case.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
