aborting a non-speculative insertion

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: aborting a non-speculative insertion
Date: 2019-06-11 15:47:07
Message-ID: CA+TgmoaMXbfpVn0B5xb4CbiMLyFrgVU4aB5rWsG4Mhiz1V+1vg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Wed, Aug 17, 2016 at 8:06 PM Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Andres Freund 2019-06-11 16:06:39 Re: aborting a non-speculative insertion
Previous Message Andres Freund 2019-06-11 07:13:14 pgsql: Don't access catalogs to validate GUCs when not connected to a D

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-06-11 15:47:11 Re: Status of the table access method work
Previous Message Andres Freund 2019-06-11 15:35:54 Re: check_recovery_target_lsn() does a PG_CATCH without a throw