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: <2272031.1650293468.1@sss.pgh.pa.us>
Date: Mon, 18 Apr 2022 10:51:08 -0400
Message-ID: <2272032.1650293468@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/2272032.1650293468%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.

>> (And TBH I see little reason to think that whether the snapshot is the
>> CatalogSnapshot or not changes things in any meaningful way.)

> It is a meaningful difference, see e.g. the bug referenced above.

Well, that's true given the current arrangements for managing
CatalogSnapshot; but that doesn't make the CatalogSnapshot any
less of a protection when it exists.  The direction I was vaguely
imagining is that we create some refcount-like infrastructure
directly ensuring that once a snapshot is used to read a toast
reference, it gets kept around until we dereference or discard
that reference.  With a scheme like that, there'd be no reason to
discriminate against a CatalogSnapshot as being the protective
snapshot.

(I hasten to add that I have no idea how to make this half-baked
plan work, and there may be better solutions anyway.)

>> While it's something to worry about, there's no reason to think
>> that v15 is any worse than prior versions in this area, is there?
>> So I'm inclined to remove this from the list of v15 open items,
>> or at least demote the remaining concern to "older bug" status.

> Yes.

OK, I'll update the open-items page.

			regards, tom lane