MIME-Version: 1.0
References: <20260706012642.f9.noahmisch@microsoft.com>
In-Reply-To: <20260706012642.f9.noahmisch@microsoft.com>
From: Xuneng Zhou <xunengzhou@gmail.com>
Date: Mon, 6 Jul 2026 13:41:35 +0800
Message-ID: 
 <CABPTF7VAubA+b32dnGGwi3rR2DA=8Lyz4R-hOxvuZLCeCTPPYw@mail.gmail.com>
Subject: Re: wait_event_type for WAIT FOR LSN
To: Noah Misch <noah@leadboat.com>
Cc: aekorotkov@gmail.com, pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CABPTF7VAubA%2Bb32dnGGwi3rR2DA%3D8Lyz4R-hOxvuZLCeCTPPYw%40mail.gmail.com>
Precedence: bulk

Hi Noah,

On Mon, Jul 6, 2026 at 9:26=E2=80=AFAM Noah Misch <noah@leadboat.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 recei=
ve data
> >  # from the frontend process to which it is connected.  This is never u=
sed 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 estab=
lishing a GSSAPI session."
> >  LIBPQWALRECEIVER_CONNECT     "Waiting in WAL receiver to establish con=
nection 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 a=
nd 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 sen=
der 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 writa=
ble,
> so I think WAIT_FOR_WAL_* events don't fit in its scope.  Sockets are jus=
t one
> of the ways to be in WAIT_FOR_WAL_*; other delay sources include local fs=
ync
> and local replay, which could be disk-bound or CPU-bound.
>
> I think WAIT_FOR_WAL_* belong in WaitEventIPC.  In the absence of objecti=
ons,
> 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 flush=
ed 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 sen=
der process."
> @@ -164,2 +161,5 @@ SAFE_SNAPSHOT       "Waiting to obtain a valid snapsh=
ot for a <literal>READ ONLY DEFER
>  SYNC_REP       "Waiting for confirmation from a remote server during syn=
chronous 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 separa=
te
> on_shmem_exit callback for xlogwait.c would make it harder to miss caller=
s
> 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.