Re: Type of wait events WalReceiverWaitStart and WalSenderWaitForWAL

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?

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.
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?

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION