Re: Should we remove vacuum_defer_cleanup_age?

Hi,

On 2023-04-24 14:36:36 +0200, Alvaro Herrera wrote:
> On 2023-Apr-22, Andres Freund wrote:
> > I'm afraid we'll need TransactionIdRetreatSafely() again, when we convert more
> > things to 64bit xids (lest they end up with the same bug as fixed by
> > be504a3e974), so it's perhaps worth thinking about how to make it less
> > confusing.
> 
> The one thing that IMO makes it less confusing is to have it return the
> value rather than modifying it in place.

Partially I made it that way because you otherwise end up repeating long
variable names multiple times within one statement, yielding long repetitive
lines...  Not sure that's a good enough reason, but ...



> > >    <para>
> > >     Replication slots overcome these disadvantages by retaining only the number
> > >     of segments known to be needed.
> > >     On the other hand, replication slots can retain so
> > >     many WAL segments that they fill up the space allocated
> > >     for <literal>pg_wal</literal>;
> > >     <xref linkend="guc-max-slot-wal-keep-size"/> limits the size of WAL files
> > >     retained by replication slots.
> > >    </para>
> > 
> > It seems a bit confusing now, because "by retaining only the number of
> > segments ..." now also should cover hs_feedback (due to merging), but doesn't.
> 
> Hah, ok.
> 

> > I think I'll push the version I had. Then we can separately word-smith the
> > section? Unless somebody protests I'm gonna do that soon.
> 
> No objection.

Cool. Pushed now.