Re: Type of wait events WalReceiverWaitStart and WalSenderWaitForWAL

On 2021/03/17 15:31, Kyotaro Horiguchi wrote:
> I think it'd be better that they are categorized by what it is waiting
> for.

Yes. And some processes can be waiting for several events at the same
moment. In this case we should pick the event that those proceses
*mainly* are waiing for, as a wait event, I think.

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

I'm not sure if these definitions are really right or not because they
seem to be slightly different from those in the document.

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

Understood.

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

+1. So our consensus is not to change the category of this event.

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

IMO this should be IPC because walreceiver is mainly waiting for the
interaction with the startup process, during this wait event. Since you can
live with IPC, probably our consensus is to use 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.

Yes, walsender is waiting for replies from the standby to arrive during
this event. But I think that it's *mainly* waiting for WAL to be flushed
in order to send it. So IPC is better for this event rather than Client.
On the other hand, wait events reported in main loop are basically
categorized in Activity, in other processes. So in the sake of consistency,
I like Activity rather than IPC, for this event.

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

IIUC walsender is mainly waiting for the socket to be writeable, to send
any pending data. So I agree to use Client for this event. Our consensus
seems not to change the category of this event.

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

Yes, walsender is waiting for replies from the standby to arrive during
this event. But I think that it's *mainly* waiting for WAL to be flushed
in order to send it. So IPC is better for this event rather than Client.
On the other hand, while the server is in idle, this event is reported for
logical walsender. This makes me think that it might be Activity, i.e.,
we should treat this as the wait event in logical walsender's main loop.
So I like Activity rather than IPC, for this event.
If we do this, it might be better to rename the event to WAIT_EVENT_LOGICAL_SENDER_MAIN.

Therefore, my current idea is

WAIT_EVENT_WAL_RECEIVER_MAIN should be in Activity (as currently it is)
WAIT_EVENT_WAL_RECEIVER_WAIT_START should be moved to in IPC
WAIT_EVENT_WAL_SENDER_MAIN should be in Activity (as currently it is)
WAIT_EVENT_WAL_SENDER_WRITE_DATA should be in Client (as currently it is)
WAIT_EVENT_WAL_SENDER_WAIT_WAL should be moved to in Activity.

Regards,

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