Re: Should we remove vacuum_defer_cleanup_age?

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: Should we remove vacuum_defer_cleanup_age?
Дата
Msg-id c93b63e02b39eff8cd3a2207796e0c9144c6ba61.camel@cybertec.at
обсуждение исходный текст
Ответ на Re: Should we remove vacuum_defer_cleanup_age?  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: Should we remove vacuum_defer_cleanup_age?  (Greg Stark <stark@mit.edu>)
Re: Should we remove vacuum_defer_cleanup_age?  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Список pgsql-hackers
On Fri, 2023-04-14 at 18:43 +0200, Alvaro Herrera wrote:
> On 2023-Apr-14, Greg Stark wrote:
> > I assume people would use hot_standby_feedback if they have streaming
> > replication.
>
> Yes, either that or a replication slot.

A replication slot doesn't do anything against snapshot conflicts,
which is what we are discussing here.  Or are we not?

>
> I find it very hard to believe that people are doing stuff with
> vacuum_defer_cleanup_age that cannot be done with either of the other
> newer mechanisms, which have also seen much wider usage and so bugs
> fixed, etc.

vacuum_defer_cleanup_age offers a more fine-grained approach.
With hot_standby_feedback you can only say "don't ever remove any dead
tuples that the standby still needs".

But perhaps you'd prefer "don't remove dead tuples unless they are
quite old", so that you can get your shorter queries on the standby
to complete, without delaying replay and without the danger that a
long running query on the standby bloats your primary.

How about this:
Let's remove vacuum_defer_cleanup_age, and put a note in the release notes
that recommends using statement_timeout and hot_standby_feedback = on
on the standby instead.
That should have pretty much the same effect, and it is measured in
time and not in the number of transactions.

Yours,
Laurenz Albe



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Should we remove vacuum_defer_cleanup_age?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Direct I/O