Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)
Date
Msg-id 2375734.1650312418@sss.pgh.pa.us
Whole thread Raw
In response to Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)  (Andres Freund <andres@anarazel.de>)
Responses Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas
Next
From: Tom Lane
Date:
Subject: Re: Why does pg_class.reltuples count only live tuples in indexes (after VACUUM runs)?