Re: Checkpointer sync queue fills up / loops around pg_usleep() are bad
От | Julien Rouhaud |
---|---|
Тема | Re: Checkpointer sync queue fills up / loops around pg_usleep() are bad |
Дата | |
Msg-id | 20220227092919.m2mkxh4kmardmqwy@jrouhaud обсуждение исходный текст |
Ответ на | Re: Checkpointer sync queue fills up / loops around pg_usleep() are bad (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Checkpointer sync queue fills up / loops around pg_usleep() are bad
|
Список | pgsql-hackers |
On Sun, Feb 27, 2022 at 06:10:45PM +0900, Michael Paquier wrote: > On Sat, Feb 26, 2022 at 01:39:42PM -0800, Andres Freund wrote: > > I suspect the easiest is to just convert that usleep to a WaitLatch(). That'd > > require adding a new enum value to WaitEventTimeout in 14. Which probably is > > fine? > > We've added wait events in back-branches in the past, so this does not > strike me as a problem as long as you add the new entry at the end of > the enum, while keeping things ordered on HEAD. +1 > In recent memory, I > think that only some of the extensions published by PostgresPro rely > on the enums in this area. Indeed, I only know of pg_wait_sampling which uses it. Note that it relies on pgstat_get_wait_event* functions, so it should only returns "???" / "unknown wait event" until you recompile it for a newer minor version and not report errors or crash. All other extensions I know of simply use whatever pg_stat_activity returns, so no impact.
В списке pgsql-hackers по дате отправления: