Hi Noah, On Mon, Jul 6, 2026 at 9:26 AM Noah Misch <[email protected]> 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.
