public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Robert Haas <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Justin Pryzby <[email protected]>
Cc: Kyotaro Horiguchi <[email protected]>
Cc: Erik Rijkers <[email protected]>
Cc: Matthias van de Meent <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)
Date: Thu, 14 Apr 2022 16:26:00 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+Tgmoap=U6yeftFb4-EbMQ1xAXE8ZZ+_GRAkTwx4L+jr+zNoA@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CA+TgmoZ1P5XxBvk1sU9s5hpHXAZf8u5oHTP1+h_otx2kHaG9QQ@mail.gmail.com>
<[email protected]>
<CA+TgmoagKyvcMip+thF8JS0Jc9kAnQnZS0xBpTetixRukdh=qg@mail.gmail.com>
<[email protected]>
<CA+TgmoaLb0j9zEfkk6bmuKM5422JenzzcJLJSiPLgwfMd+xnBw@mail.gmail.com>
<[email protected]>
<CA+TgmoYKWXhYRRSHwMTo-N48i64jOvq1yYmwrz7vHKFGnOyy8Q@mail.gmail.com>
<[email protected]>
<CA+Tgmob93_YftfhrSF+OpNWXWtv2bq774yBH3JxPiJf=-DxoiA@mail.gmail.com>
<[email protected]>
<CA+Tgmoap=U6yeftFb4-EbMQ1xAXE8ZZ+_GRAkTwx4L+jr+zNoA@mail.gmail.com>
Robert Haas <[email protected]> writes:
> On Thu, Apr 14, 2022 at 3:05 PM Tom Lane <[email protected]> wrote:
>> If you don't register it, then you need to also make sure that it's
>> destroyed whenever that older snapshot is.
> Well, if that's true, then I agree that it's a good argument against
> that approach. But I guess I'm confused as to why we'd end up in that
> situation. Suppose we do these two things:
> 1. Decree that SnapshotResetXmin calls InvalidateCatalogSnapshot. It's
> the other way around right now, but that's only because we're
> registering the catalog snapshot.
> 2. Bomb out in GetCatalogSnapshot if you don't have an active or
> registered snapshot already.
> Is there some reason we'd need any more infrastructure than that?
Yes.
1. Create snapshot 1 (beginning of transaction).
2. Create catalog snapshot (okay because of snapshot 1).
3. Create snapshot 2.
4. Destroy snapshot 1.
5. Catalog snapshot is still there and is now the oldest.
The implementation you propose would have to also forbid this sequence
of events, which is (a) difficult and (b) would add instability to the
system, since there's really no reason that this should be Not OK.
I'm basically not on board with adding complication to make the system
less performant and more brittle, and I don't see how the direction
you want to go isn't that.
(BTW, this thought experiment also puts a hole in the test added by
277692220: even if HaveRegisteredOrActiveSnapshot were doing what
it claims to do, it would allow use of the catalog snapshot for
detoasting after step 4, which I suppose is not what Andres intended.)
regards, tom lane
view thread (27+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox