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.