Re: Should we remove vacuum_defer_cleanup_age?
От | Andres Freund |
---|---|
Тема | Re: Should we remove vacuum_defer_cleanup_age? |
Дата | |
Msg-id | 20230322170048.ffbnfr5o2jrjgb2f@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Should we remove vacuum_defer_cleanup_age? (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: Should we remove vacuum_defer_cleanup_age?
Re: Should we remove vacuum_defer_cleanup_age? |
Список | pgsql-hackers |
Hi, On 2023-03-22 11:44:20 -0500, Justin Pryzby wrote: > On Sat, Mar 18, 2023 at 10:33:57AM +0100, Alvaro Herrera wrote: > > On 2023-Mar-17, Andres Freund wrote: > > > > > I started writing a test for vacuum_defer_cleanup_age while working on the fix > > > referenced above, but now I am wondering if said energy would be better spent > > > removing vacuum_defer_cleanup_age alltogether. > > > > +1 I agree it's not useful anymore. > > > > > I don't think I have the cycles to push this through in the next weeks, but if > > > we agree removing vacuum_defer_cleanup_age is a good idea, it seems like a > > > good idea to mark it as deprecated in 16? > > > > Hmm, for the time being, can we just "disable" it by disallowing to set > > the GUC to a value different from 0? Then we can remove the code later > > in the cycle at leisure. > > It can be useful to do a "rolling transition", and it's something I do > often. > > But I can't see why that would be useful here? It seems like something > that could be done after the feature freeze. It's removing a feature, > not adding one. It wasn't actually that much work to write a patch to remove vacuum_defer_cleanup_age, see the attached. I don't know whether others think we should apply it this release, given the "late submission", but I tend to think it's not worth caring the complication of vacuum_defer_cleanup_age forward. Greetings, Andres Freund
Вложения
В списке pgsql-hackers по дате отправления: