Re: Error "initial slot snapshot too large" in create replication slot - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Error "initial slot snapshot too large" in create replication slot
Date
Msg-id 20220401.155316.930989254339879136.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Error "initial slot snapshot too large" in create replication slot  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: Error "initial slot snapshot too large" in create replication slot  (Jacob Champion <jchampion@timescale.com>)
List pgsql-hackers
At Fri, 01 Apr 2022 14:44:30 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
> At Sun, 13 Feb 2022 17:35:38 +0300, Yura Sokolov <y.sokolov@postgrespro.ru> wrote in 
> > And there are checks for `takenDuringRecovery` in `heapgetpage` and
> > `heapam_scan_sample_next_tuple`. Are this checks affected by the change?
> > Neither the preceding discussion nor commit message answer me.
> 
> The snapshot works correctly, but for the heapgetpage case, it foces
> all_visible to be false.  That unnecessarily prevents visibility check
> from skipping.
> 
> An annoying thing in SnapBuildInitialSnapshot is that we don't know
> the number of xids before looping over the xid range, and we don't
> want to bother sorting top-level xids and subxids unless we have to do
> so.
> 
> Is it better that we hassle in SnapBuildInitialSnapshot to create a
> !takenDuringRecovery snapshot?

So this is that. v5 creates a regular snapshot.

By the way, is there any chance this could be committed to 15?
Otherwise I'll immediately move this to the next CF.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To:
Next
From: Amit Langote
Date:
Subject: Re: generic plans and "initial" pruning