Hi,
On 2022-04-17 11:51:58 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2022-04-16 14:42:39 -0400, Tom Lane wrote:
> >> I think (based on the above argument) that what it intends to enforce
> >> is not really the system design we need, but it certainly isn't
> >> helping anyone that it enforces that design incorrectly.
>
> > I think it's approximately right for the current caller. But that caller
> > likely needs an improved design around snapshots...
>
> Yeah, I think the real issue is that checking
> HaveRegisteredOrActiveSnapshot in this way doesn't provide a very
> good guarantee of what we really want to know, which is that the
> session's advertised xmin is old enough to prevent removal of
> whatever toast data we're trying to fetch.
Right. It's better than what was there before though - I added
HaveRegisteredOrActiveSnapshot() in the course of
7c38ef2a5d6cf6d8dc3834399d7a1c364d64ce64. Where the problem was that we
didn't have *any* snapshot other than the catalog snapshot, and the
catalog snapshot only sometimes (iirc for that bug it depended on the
order in which objects were deleted). That makes such bugs much harder
to detect.
> 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.
> I don't yet see a practical way to check for the real concern.
> 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.
Greetings,
Andres Freund
