Re: old_snapshot_threshold bottleneck on replica - Mailing list pgsql-hackers

From Maxim Orlov
Subject Re: old_snapshot_threshold bottleneck on replica
Date
Msg-id CACG=ezaUKQbujov95xgutC9Bb2-+6JsTcSmqDubwMi6uqNt=2g@mail.gmail.com
Whole thread Raw
In response to Re: old_snapshot_threshold bottleneck on replica  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers

On Fri, 27 Jan 2023 at 18:18, Robert Haas <robertmhaas@gmail.com> wrote:

Interesting, but it's still not entirely clear to me from reading the
comments why we should think that this is safe.
 
In overall, I think this is safe, because we do not change algorithm here. More specific, threshold_timestamp have only used in a few cases:
1). To get the latest value by calling GetOldSnapshotThresholdTimestamp. This will work, since we only change the sync type here from the spinlock to an atomic.
2). In TransactionIdLimitedForOldSnapshots, but here no changes in the behaviour will be done. Sync model will be the save as before the patch.
3). In SnapshotTooOldMagicForTest, which is a stub to make old_snapshot_threshold tests appear "working". But no coherence with the threshold_xid here.

So, we have a two use cases for the threshold_timestamp:
a). When the threshold_timestamp is used in conjunction with the threshold_xid. We must use spinlock to sync.
b). When the threshold_timestamp is used without conjunction with the threshold_xid. In this case, we use atomic values.

--
Best regards,
Maxim Orlov.

pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: MacOS: xsltproc fails with "warning: failed to load external entity"
Next
From: Maxim Orlov
Date:
Subject: Re: Add SHELL_EXIT_CODE to psql