Horton

Re: A few patches to clarify snapshot management

Heikki Linnakangas <hlinnaka@iki.fi>

View thread
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2025-03-13T15:27:39Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Use ereport() rather than elog()

  2. Revert GetTransactionSnapshot() to return historic snapshot during LR

  3. Improve snapmgr.c comment

  4. Assert that a snapshot is active or registered before it's used

  5. Don't allow GetTransactionSnapshot() in logical decoding

  6. Remove unnecessary GetTransactionSnapshot() calls

  7. snapshot scalability: Don't compute global horizons while building snapshots.

Attachments

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)