Re: Should we remove vacuum_defer_cleanup_age? - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Should we remove vacuum_defer_cleanup_age?
Date
Msg-id 0DAF1BDA-EF76-44A2-8BD1-469D7590B2F9@yesql.se
Whole thread Raw
In response to Re: Should we remove vacuum_defer_cleanup_age?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
> On 24 Mar 2023, at 21:27, Andres Freund <andres@anarazel.de> wrote:
> On 2023-03-23 10:18:35 +0100, Daniel Gustafsson wrote:
>>> On 22 Mar 2023, at 18:00, Andres Freund <andres@anarazel.de> wrote:
>>
>>> It wasn't actually that much work to write a patch to remove
>>> vacuum_defer_cleanup_age, see the attached.
>>
>> -    and <xref linkend="guc-vacuum-defer-cleanup-age"/> provide protection against
>> +    provides protection against
>>     relevant rows being removed by vacuum, but the former provides no
>>     protection during any time period when the standby is not connected,
>>     and the latter often needs to be set to a high value to provide adequate
>>
>> Isn't "the latter" in the kept part of the sentence referring to the guc we're
>> removing here?
>
> You're right. That paragraph generally seems a bit off. In HEAD:
>
> ...
>
> Replication slots alone don't prevent row removal, that requires
> hot_standby_feedback to be used as well.
>
> A minimal rephrasing would be:
>   <para>
>    Similarly, <xref linkend="guc-hot-standby-feedback"/> on its own, without
>    also using a replication slot, provides protection against relevant rows
>    being removed by vacuum, but provides no protection during any time period
>    when the standby is not connected.  Replication slots overcome these
>    disadvantages.
>   </para>

+1, that's definitely an improvement.

--
Daniel Gustafsson




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Make EXPLAIN generate a generic plan for a parameterized query
Next
From: David Rowley
Date:
Subject: Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL