At Wed, 26 Jul 2023 16:41:25 -0700, Nathan Bossart <nathandbossart@gmail.com> wrote in
> On Mon, Mar 13, 2023 at 02:16:31PM -0700, Nathan Bossart wrote:
> I started on the former approach (work-in-progress patch attached), but I
> figured I'd ask whether folks are alright with this before I spend more
> time on it. Many of the sleeps in question are relatively short, are
> intended for debugging, or are meant to prevent errors from repeating as
> fast as possible, so I don't know if we should bother adding interrupt
> handling support.
It is responsive to an immediate shutdown. I think that's fine, as
things might become overly complex if we aim for it to respond to fast
shutdown as well.
The pg_msleep() implemented in the patch accepts a wait event type,
and some event types other than WAIT_EVENT_PG_SLEEP are passed to it.
WAIT_EVENT_CHECKPOINTER_MAIN:
- At checkpointer.c:309, it is in a long-jump'ed block, where out of
the main loop.
- At checkpointer.c:1005: RequestCheckpoint is not executed on checkpointer.
WAIT_EVENT_ARCHIVER_MAIN:
- At pgarch.c:453,485: They are not at the main-loop level idle-waiting.
WAIT_EVENT_PRE/POST_AUTH_DELAY:
- These are really useless since they're not seen anywhere. Client
backends don't show up in pg_stat_activity until this sleep
finishes. (We could use ps-display instead, but...)
WAIT_EVENT_VACUUM_DELAY:
- This behaves the same as it did before the change. Actually, we
don't want to use WAIT_EVENT_PG_SLEEP for it.
So, we have at least one sensible use case for the parameter, which
seems to be sufficient reason.
I'm not sure if others will agree, but I'm leaning towards providing a
dedicated WaitEventSet for the new sleep function.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center