Re: wait_event_type for WAIT FOR LSN

On Tue, Jul 7, 2026 at 4:29 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
>
> On Mon, Jul 06, 2026 at 01:41:35PM +0800, Xuneng Zhou wrote:
> > 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.
>
> It partially does. In favor of WAIT_FOR_STANDBY_CONFIRMATION in WaitEventIPC:
>
> - It's much like SYNC_REP, which is in WaitEventIPC.
> - It's a condition variable wait, not a socket wait.
>
> In favor of keeping WAIT_FOR_STANDBY_CONFIRMATION in WaitEventClient:
>
> - The standard for reclassifying a wait event post-release is higher, since it
> impedes comparing waits across versions.
> - The condition variable is set based on a socket read, and it's fair to treat
> the condition variable layer as an implementation detail of little concern
> to users.
>
> Overall, I lean toward not changing WAIT_FOR_STANDBY_CONFIRMATION.

Thanks for clarification. I'm also ok with the status quo.

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