Re: Checkpointer sync queue fills up / loops around pg_usleep() are bad - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Checkpointer sync queue fills up / loops around pg_usleep() are bad
Date
Msg-id 20220227092919.m2mkxh4kmardmqwy@jrouhaud
Whole thread Raw
In response to Re: Checkpointer sync queue fills up / loops around pg_usleep() are bad  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Checkpointer sync queue fills up / loops around pg_usleep() are bad  (Thomas Munro <thomas.munro@gmail.com>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Checkpointer sync queue fills up / loops around pg_usleep() are bad
Next
From: Jille Timmermans
Date:
Subject: Support for grabbing multiple consecutive values with nextval()