Re: Type of wait events WalReceiverWaitStart and WalSenderWaitForWAL

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: masao(dot)fujii(at)oss(dot)nttdata(dot)com
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Type of wait events WalReceiverWaitStart and WalSenderWaitForWAL
Date: 2021-03-17 06:31:37
Message-ID: 20210317.153137.1956279574444261406.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Tue, 16 Mar 2021 15:42:27 +0900, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote in
>
>
> On 2021/03/16 11:59, Kyotaro Horiguchi wrote:
> > At Tue, 16 Mar 2021 03:12:54 +0900, Fujii Masao
> > <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote in
> >> The wait event WalReceiverWaitStart has been categorized in the type
> >> Client.
> >> But why? Walreceiver is waiting for startup process to set the lsn and
> >> timeline while it is reporting WalReceiverWaitStart. So its type
> >> should be IPC,
> >> instead?
> >>
> >> The wait event WalSenderWaitForWAL has also been categorized in the
> >> type
> >> Client. While this wait event is being reported, logical replication
> >> walsender
> >> is waiting for not only new WAL to be flushed but also the socket to
> >> be
> >> readable and writeable (if there is pending data). I guess that this
> >> is why
> >> its type is Client. But ISTM walsender is *mainly* waiting for new WAL
> >> to be
> >> flushed by other processes during that period, so I think that it's
> >> better
> >> to use IPC as the type of the wait event WalSenderWaitForWAL. Thought?
> > I agree that it's definitely not a client wait. It would be either
> > activity or IPC. My reasoning for the latter is it's similar to
> > WAIT_EVENT_WAL_RECEIVER_MAIN since both are a wait while
> > WalReceiverMain to continue. With a difference thatin walreceiver
> > hears where to start in the latter state.
> > I don't object if it were categorized to IPC, though.
>
> Ok. And on my further thought;
> There are three calls to WalSndWait() in walsender.c as follow.
>
> 1. WalSndLoop() calls WalSndWait() with the wait event
> "Activity:WalSenderMain". Both physical and logical replication
> walsenders
> use this function.
> 2. WalSndWriteData() calls WalSndWait() with the wait event
> "Client:WalSenderWriteData". Only logical replication walsender uses
> this function.
> 3. WalSndWaitForWal() calls WalSndWait() with the wait event
> "Client:WalSenderWaitForWAL". Only logical replication walsender
> uses this function.
>
> These three WalSndWait() basically do the same thing, i.e., wait for
> the latch
> set, timeout, postmaster death, the readable and writeable socket. So
> you
> may think that it's strange to categorize them differently. Maybe it's
> better
> to categorize all of them in Actvitiy?

I think it'd be better that they are categorized by what it is waiting
for.

Activity is waiting for something gating me to be released.

IPC is waiting for the response for a request previously sent to
another process.

Wait-client is waiting for the peer over a network connection to allow
me to proceed activity.

So whether the three fall into the same category or not doesn't matter
to me.

WAIT_EVENT_WAL_RECEIVER_MAIN(WalReceiverMain) is waiting for new data
to arrive. This looks like an activity to me.

WAIT_EVENT_WAL_RECEIVER_WAIT_START is waiting for waiting for starup
process to kick me. So it may be either IPC or Activity. Since
walreceiver hasn't sent anything to startup, so it's activity, rather
than IPC. However, the behavior can be said that it convey a piece of
information from startup to wal receiver so it also can be said to be
an IPC. (That is the reason why I don't object for IPC.)

1(WAIT_EVENT_WAL_SENDER_MAIN, currently an activity) is waiting for
something to happen on the connection to the peer
receiver/worker. This might either be an activity or an wait_client,
but I prefer it to be wait_client, as the same behavior of a client
backend is categorizes as wait_client.

2 (WAIT_EVENT_WAL_SENDER_WRITE_DATA, currently a wait_client) is the
same to 1.

3 (WAIT_EVENT_WAL_SENDER_WAIT_WAL, currently a wait_client) is the
same to 1.

As the result I'd prefer to categorize all of them to Activity.

> Or it's better to categorize only WalSenderMain in Activity, and the
> others
> in IPC because only WalSenderMain is reported in walsender's main
> loop.

I don't think 1, 2 and 3 are Activities. And Activity necessariry
means main loop as I descrived. And as I said,
WAIT_EVENT_WAL_RECEIVER_WAIT_START seems in between IPC and activity
so I don't object to categorized it to IPC.

> At least for me the latter is better because the former, i.e.,
> reporting
> three different events for walsender's activity in main loop seems a
> bit strange.
> Thought?

Maybe it's the difference in what one consider as the same event.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2021-03-17 06:36:50 Re: Type of wait events WalReceiverWaitStart and WalSenderWaitForWAL
Previous Message Julien Rouhaud 2021-03-17 06:06:57 Re: pl/pgsql feature request: shorthand for argument and local variable references