| From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Subject: | Re: Checkpointer sync queue fills up / loops around pg_usleep() are bad |
| Date: | 2022-02-27 09:29:19 |
| Message-ID: | 20220227092919.m2mkxh4kmardmqwy@jrouhaud |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jille Timmermans | 2022-02-27 09:42:25 | Support for grabbing multiple consecutive values with nextval() |
| Previous Message | Michael Paquier | 2022-02-27 09:10:45 | Re: Checkpointer sync queue fills up / loops around pg_usleep() are bad |