wait_event_type for WAIT FOR LSN

commit 7a39f43 wrote:
> --- a/src/backend/utils/activity/wait_event_names.txt
> +++ b/src/backend/utils/activity/wait_event_names.txt
> @@ -76,34 +76,35 @@ ABI_compatibility:
>  # Wait Events - Client
>  #
>  # Use this category when a process is waiting to send data to or receive data
>  # from the frontend process to which it is connected.  This is never used for
>  # a background process, which has no client connection.
>  #
>  
>  Section: ClassName - WaitEventClient
>  
>  CLIENT_READ	"Waiting to read data from the client."
>  CLIENT_WRITE	"Waiting to write data to the client."
>  GSS_OPEN_SERVER	"Waiting to read data from the client while establishing a GSSAPI session."
>  LIBPQWALRECEIVER_CONNECT	"Waiting in WAL receiver to establish connection to remote server."
>  LIBPQWALRECEIVER_RECEIVE	"Waiting in WAL receiver to receive data from remote server."
>  SSL_OPEN_SERVER	"Waiting for SSL while attempting connection."
>  WAIT_FOR_STANDBY_CONFIRMATION	"Waiting for WAL to be received and flushed by the physical standby."
> -WAIT_FOR_WAL_FLUSH	"Waiting for WAL flush to reach a target LSN on a primary."
> +WAIT_FOR_WAL_FLUSH	"Waiting for WAL flush to reach a target LSN on a primary or standby."
>  WAIT_FOR_WAL_REPLAY	"Waiting for WAL replay to reach a target LSN on a standby."
> +WAIT_FOR_WAL_WRITE	"Waiting for WAL write to reach a target LSN on a standby."
>  WAL_SENDER_WAIT_FOR_WAL	"Waiting for WAL to be flushed in WAL sender process."
>  WAL_SENDER_WRITE_DATA	"Waiting for any activity when processing replies from WAL receiver in WAL sender process."
>  
>  ABI_compatibility:

WaitEventClient is about waiting for a socket to become readable or writable,
so I think WAIT_FOR_WAL_* events don't fit in its scope.  Sockets are just one
of the ways to be in WAIT_FOR_WAL_*; other delay sources include local fsync
and local replay, which could be disk-bound or CPU-bound.

I think WAIT_FOR_WAL_* belong in WaitEventIPC.  In the absence of objections,
I'll change it that way:

--- a/src/backend/utils/activity/wait_event_names.txt
+++ b/src/backend/utils/activity/wait_event_names.txt
@@ -91,5 +91,2 @@ SSL_OPEN_SERVER	"Waiting for SSL while attempting connection."
 WAIT_FOR_STANDBY_CONFIRMATION	"Waiting for WAL to be received and flushed by the physical standby."
-WAIT_FOR_WAL_FLUSH	"Waiting for WAL flush to reach a target LSN on a primary or standby."
-WAIT_FOR_WAL_REPLAY	"Waiting for WAL replay to reach a target LSN on a standby."
-WAIT_FOR_WAL_WRITE	"Waiting for WAL write to reach a target LSN on a standby."
 WAL_SENDER_WAIT_FOR_WAL	"Waiting for WAL to be flushed in WAL sender process."
@@ -164,2 +161,5 @@ SAFE_SNAPSHOT	"Waiting to obtain a valid snapshot for a READ ONLY DEFER
 SYNC_REP	"Waiting for confirmation from a remote server during synchronous replication."
+WAIT_FOR_WAL_FLUSH	"Waiting for WAL flush to reach a target LSN on a primary or standby."
+WAIT_FOR_WAL_REPLAY	"Waiting for WAL replay to reach a target LSN on a standby."
+WAIT_FOR_WAL_WRITE	"Waiting for WAL write to reach a target LSN on a standby."
 WAL_RECEIVER_EXIT	"Waiting for the WAL receiver to exit."


As further rationale, WaitEventClient says "never used for a background
process".  By xlogwait.c sizing its shmem to include NUM_AUXILIARY_PROCS, it's
reserving the right to accept calls from background processes.  As a side note
related to that, the placement of WaitLSNCleanup() in ProcKill() but not
AuxiliaryProcKill() would also need to change before welcoming auxiliary
process use.  Perhaps better than adding to AuxiliaryProcKill(), a separate
on_shmem_exit callback for xlogwait.c would make it harder to miss callers
needing it.