From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Robert Haas <robertmhaas@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>,
        Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
        Erik Rijkers <er@xs4all.nl>,
        Matthias van de Meent <boekewurm+postgres@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)
In-reply-to: <20220418143901.mdxs53vq3g4u2skp@alap3.anarazel.de>
References: <CA+TgmoYKWXhYRRSHwMTo-N48i64jOvq1yYmwrz7vHKFGnOyy8Q@mail.gmail.com> <1527714.1649957811@sss.pgh.pa.us> <CA+Tgmob93_YftfhrSF+OpNWXWtv2bq774yBH3JxPiJf=-DxoiA@mail.gmail.com> <1535399.1649963150@sss.pgh.pa.us> <CA+Tgmoap=U6yeftFb4-EbMQ1xAXE8ZZ+_GRAkTwx4L+jr+zNoA@mail.gmail.com> <1542208.1649967960@sss.pgh.pa.us> <CA+TgmoY5A+JoVZODuLaLiu6s=sNKPdOv-Mf2K43yKfg6Cp5MDw@mail.gm! ail.com> <1971135.1650134559@sss.pgh.pa.us> <20220417133112.phzg25rs66w5zipv@alap3.anarazel.de> <2131038.1650210718@sss.pgh.pa.us> <20220418143901.mdxs53vq3g4u2skp@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Mon, 18 Apr 2022 07:39:01 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2375733.1650312418.1@sss.pgh.pa.us>
Date: Mon, 18 Apr 2022 16:06:58 -0400
Message-ID: <2375734.1650312418@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/2375734.1650312418%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2022-04-17 11:51:58 -0400, Tom Lane wrote:
>> The fact that we have a snapshot at the instant of fetch doesn't prove
>> that it existed continually since we fetched the toast reference,
>> which seems to be the condition we actually need to assure.

> Right.

BTW, after thinking about this for a bit I am less concerned than
I was about the system being full of bugs of this ilk.  The executor
per se should be fine because it does everything under a live snapshot.
We had bugs with cases that shove executor output into long-lived
tuplestores, but we've dealt with that scenario.  Catalog updates
performed on tuples fetched from a catalog scan seem safe enough too.
Andres was worried about catalog updates performed using tuples fetched
from catcache, but that's not a problem because we detoasted every value
when it went into the catcache, cf 08e261cbc.

(Mind you, 08e261cbc's solution is risky performancewise, because it
means we have to re-toast every value during such catalog updates,
instead of being able to carry the old values of unchanged columns
forward.  But it's not a correctness bug.)

(Also, the whining I did in 08e261cbc's commit message is no longer
relevant now that we read catalogs with MVCC snapshots.)

There may be some corner cases that aren't described by any of these
three blanket scenarios, but they've got to be pretty few and far
between.

			regards, tom lane