Re: wait_event_type for WAIT FOR LSN

Hi Noah,

On Mon, Jul 6, 2026 at 9:26 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
>
> 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:

Thanks for raising this. It makes sense to me to move these events to
the WaitEventIPC session. I'm wondering whether this reasoning also
applies to WAIT_FOR_STANDBY_CONFIRMATION.

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

Good catch! Currently, we have no actual background processes to make
use of the wait-for facility, but things could change in the upcoming
releases. A dedicated on_shmem_exit callback for xlogwait.c also makes
sense to me. I'll prepare a patch for that.

--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.