Re: allow changing autovacuum_max_workers without restarting
От | Peter Eisentraut |
---|---|
Тема | Re: allow changing autovacuum_max_workers without restarting |
Дата | |
Msg-id | 15005c8c-7676-43b7-a440-787b101cfdf5@eisentraut.org обсуждение исходный текст |
Ответ на | Re: allow changing autovacuum_max_workers without restarting (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: allow changing autovacuum_max_workers without restarting
Re: allow changing autovacuum_max_workers without restarting |
Список | pgsql-hackers |
On 28.04.25 16:41, Nathan Bossart wrote: > On Mon, Apr 28, 2025 at 09:14:54AM -0400, Tom Lane wrote: >> Peter Eisentraut <peter@eisentraut.org> writes: >>> This initdb output seems, well, kinda fake, which it is by its own >>> admission. >> >> Agreed. >> >>> Could we do this less fake maybe like this: >>> selecting default "max_connections", "autovacuum_worker_slots" ... 100, 16 >>> with the actual wait at the "..."? >> >> Perhaps that would be all right ... >> >>> (It doesn't seem impossible that someone will want to add more default >>> selecting for various worker or process slots, and this would allow adding >>> these easily, versus adding more "fake" output lines.) >> >> ... but I can't see this approach scaling to three or four or five >> outputs. The line would get unreasonably long. >> >> My own proposal given the way it works now is to just print >> max_connections and not mention autovacuum_worker_slots at all. >> Our choice for max_connections is worth reporting, but I don't >> feel that everything derived from it needs to be reported. > > I'm fine with either of these ideas. If I had to choose one, I'd just > remove the autovacuum_worker_slots report for the reasons Tom noted. Yes, removing the report is also fine by me. > However, weren't we considering reverting some of this stuff [0]? I see > that sawshark is now choosing max_connections = 40 and > autovacuum_worker_slots = 6, and since there are no other apparent related > buildfarm failures, I'm assuming that nobody else is testing the 60 > semaphores case anymore. > > [0] https://postgr.es/m/618497.1742347456%40sss.pgh.pa.us (I don't have any thoughts on this.)
В списке pgsql-hackers по дате отправления: