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 2549926.1650378996@sss.pgh.pa.us
Whole thread Raw
In response to Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Apr 18, 2022 at 4:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> My first thought whenever anything like this comes up is cursors,
> especially but not only holdable cursors. Also, plpgsql variables,
> maybe mixed with embedded COMMIT/ROLLBACK.

Those exact cases have had detoasting bugs in the past and are now fixed.

> I don't find it
> particularly hard to believe we have some bugs in
> insufficiently-well-considered parts of the system that pass around
> datums outside of the normal executor flow, but I don't know exactly
> how to find them all, either.

I'm not here to claim that there are precisely zero remaining bugs
of this ilk.  I'm just saying that I think we've flushed out most
of them.  I think there is some value in trying to think of a way
to prove that none remain, but it's not a problem we can solve
for v15.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: error handling in pqRowProcessor broken
Next
From: Tom Lane
Date:
Subject: Re: automatically generating node support functions