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

From Thomas Munro
Subject Re: old_snapshot_threshold bottleneck on replica
Date
Msg-id CA+hUKG+=s+8+Dto0rE7B3oJREzBfapOuLGFbYamNiOuhJs5vYw@mail.gmail.com
Whole thread Raw
In response to Re: old_snapshot_threshold bottleneck on replica  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: old_snapshot_threshold bottleneck on replica
List pgsql-hackers
On Fri, Sep 8, 2023 at 2:00 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Fri, Sep 8, 2023 at 1:53 PM Peter Geoghegan <pg@bowt.ie> wrote:
> > Thanks for working on this. Though I wonder why you didn't do
> > something closer to a straight revert of the feature. Why is nbtree
> > still passing around snapshots needlessly?

The code moved around quite a few times over several commits and quite
a lot since then, which is why I didn't go for straight revert, but
clearly the manual approach risked missing things.  I think the
attached removes all unused 'snapshot' arguments from AM-internal
functions.  Checked by compiling with clang's -Wunused-parameters, and
then searching for 'snapshot', and excluding the expected cases.

> > Also, why are there still many comments referencing the feature?
> > There's the one above should_attempt_truncation(), for example.
> > Another appears above init_toast_snapshot(). Are these just
> > oversights, or was it deliberate? You said something about retaining
> > vestiges.

Stray comments removed.

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Impact of checkpointer during pg_upgrade
Next
From: Tatsuo Ishii
Date:
Subject: Re: Row pattern recognition