Re: A few patches to clarify snapshot management

On 06/01/2025 23:30, Heikki Linnakangas wrote:
> On 20/12/2024 19:31, Heikki Linnakangas wrote:
>>> /*
>>>  * Struct representing all kind of possible snapshots.
>>>  *
>>>  * There are several different kinds of snapshots:
>>>  * * Normal MVCC snapshots
>>>  * * MVCC snapshots taken during recovery (in Hot-Standby mode)
>>>  * * Historic MVCC snapshots used during logical decoding
>>>  * * snapshots passed to HeapTupleSatisfiesDirty()
>>>  * * snapshots passed to HeapTupleSatisfiesNonVacuumable()
>>>  * * snapshots used for SatisfiesAny, Toast, Self where no members are
>>>  *     accessed.
>>>  *
>>>  * TODO: It's probably a good idea to split this struct using a NodeTag
>>>  * similar to how parser and executor nodes are handled, with one
>>> type for
>>>  * each different kind of snapshot to avoid overloading the meaning of
>>>  * individual fields.
>>>  */
>>> typedef struct SnapshotData
>>
>> I'm thinking of implementing that TODO, splitting SnapshotData into
>> separate structs like MVCCSnapshotData, SnapshotDirtyData, etc. It
>> seems to me most places can assume that you're dealing with MVCC
>> snapshots, and if we had separate types for them, could be using
>> MVCCSnapshot instead of the generic Snapshot. Only the table and index
>> AM functions need to deal with non-MVCC snapshots.
>
> Here's a draft of that. Going through this exercise clarified a few
> things to me that I didn't realize before:
>
> - The executor only deals with MVCC snapshots. Special snapshots are
> only for the lower-level AM interfaces.
> - Only MVCC snapshots can be pushed to the active stack
> - Only MVCC or historic MVCC snapshots can be registered with a resource
> owner

I committed the patches adding comments on Tuesday. Here's an updated
version of the patch to split SnapshotData into different structs.

The second, new patch simplifies the historic snapshot reference
counting during logical decoding. It's in principle independent from the
first patch, but it was hard to see how the opportunity before splitting
the structs.

--
Heikki Linnakangas
Neon (https://neon.tech)