public inbox for [email protected]  

help / color / mirror / Atom feed

From: Noah Misch <[email protected]>
To: Xuneng Zhou <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: wait_event_type for WAIT FOR LSN
Date: Mon, 6 Jul 2026 13:29:42 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <CABPTF7VAubA+b32dnGGwi3rR2DA=8Lyz4R-hOxvuZLCeCTPPYw@mail.gmail.com>
References: <[email protected]>
	<CABPTF7VAubA+b32dnGGwi3rR2DA=8Lyz4R-hOxvuZLCeCTPPYw@mail.gmail.com>

On Mon, Jul 06, 2026 at 01:41:35PM +0800, Xuneng Zhou wrote:
> 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.

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.

view thread (7+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: wait_event_type for WAIT FOR LSN
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox