public inbox for [email protected]
help / color / mirror / Atom feedwait_event_type for WAIT FOR LSN
7+ messages / 3 participants
[nested] [flat]
* wait_event_type for WAIT FOR LSN
@ 2026-07-06 01:26 Noah Misch <[email protected]>
2026-07-06 05:41 ` Re: wait_event_type for WAIT FOR LSN Xuneng Zhou <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Noah Misch @ 2026-07-06 01:26 UTC (permalink / raw)
To: [email protected]; [email protected]; +Cc: pgsql-hackers
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:
--- 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.
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: wait_event_type for WAIT FOR LSN
2026-07-06 01:26 wait_event_type for WAIT FOR LSN Noah Misch <[email protected]>
@ 2026-07-06 05:41 ` Xuneng Zhou <[email protected]>
2026-07-06 20:29 ` Re: wait_event_type for WAIT FOR LSN Noah Misch <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Xuneng Zhou @ 2026-07-06 05:41 UTC (permalink / raw)
To: Noah Misch <[email protected]>; +Cc: [email protected]; pgsql-hackers
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.
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: wait_event_type for WAIT FOR LSN
2026-07-06 01:26 wait_event_type for WAIT FOR LSN Noah Misch <[email protected]>
2026-07-06 05:41 ` Re: wait_event_type for WAIT FOR LSN Xuneng Zhou <[email protected]>
@ 2026-07-06 20:29 ` Noah Misch <[email protected]>
2026-07-07 14:08 ` Re: wait_event_type for WAIT FOR LSN Xuneng Zhou <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Noah Misch @ 2026-07-06 20:29 UTC (permalink / raw)
To: Xuneng Zhou <[email protected]>; +Cc: [email protected]; pgsql-hackers
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.
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: wait_event_type for WAIT FOR LSN
2026-07-06 01:26 wait_event_type for WAIT FOR LSN Noah Misch <[email protected]>
2026-07-06 05:41 ` Re: wait_event_type for WAIT FOR LSN Xuneng Zhou <[email protected]>
2026-07-06 20:29 ` Re: wait_event_type for WAIT FOR LSN Noah Misch <[email protected]>
@ 2026-07-07 14:08 ` Xuneng Zhou <[email protected]>
2026-07-07 14:38 ` Re: wait_event_type for WAIT FOR LSN Alexander Korotkov <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Xuneng Zhou @ 2026-07-07 14:08 UTC (permalink / raw)
To: Noah Misch <[email protected]>; +Cc: [email protected]; pgsql-hackers
On Tue, Jul 7, 2026 at 4:29 AM Noah Misch <[email protected]> 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 <[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.
Thanks for clarification. I'm also ok with the status quo.
--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: wait_event_type for WAIT FOR LSN
2026-07-06 01:26 wait_event_type for WAIT FOR LSN Noah Misch <[email protected]>
2026-07-06 05:41 ` Re: wait_event_type for WAIT FOR LSN Xuneng Zhou <[email protected]>
2026-07-06 20:29 ` Re: wait_event_type for WAIT FOR LSN Noah Misch <[email protected]>
2026-07-07 14:08 ` Re: wait_event_type for WAIT FOR LSN Xuneng Zhou <[email protected]>
@ 2026-07-07 14:38 ` Alexander Korotkov <[email protected]>
2026-07-08 00:19 ` Re: wait_event_type for WAIT FOR LSN Alexander Korotkov <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Alexander Korotkov @ 2026-07-07 14:38 UTC (permalink / raw)
To: Xuneng Zhou <[email protected]>; +Cc: Noah Misch <[email protected]>; pgsql-hackers
Hi!
On Tue, Jul 7, 2026 at 5:08 PM Xuneng Zhou <[email protected]> wrote:
>
> On Tue, Jul 7, 2026 at 4:29 AM Noah Misch <[email protected]> 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 <[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.
>
> Thanks for clarification. I'm also ok with the status quo.
Thanks to Noah for raising this. Thanks to Xuneng for the feedback.
OK, let's leave WAIT_FOR_STANDBY_CONFIRMATION as is, but move
WAIT_FOR_WAL_* to WaitEventIPC. The patch is attached. I'm going to
push it if no objections.
------
Regards,
Alexander Korotkov
Supabase
Attachments:
[application/octet-stream] v1-0001-Move-WAIT_FOR_WAL_-wait-events-from-Client-to-IPC.patch (2.7K, ../../CAPpHfdtF3E5jtWKWUVj+Lm+Jm48_6b=RHtPPJtvFa-Wpr5w2Dg@mail.gmail.com/2-v1-0001-Move-WAIT_FOR_WAL_-wait-events-from-Client-to-IPC.patch)
download | inline diff:
From c7f788a21d627e36e1b0ec9dc5ca0a5a06a52c19 Mon Sep 17 00:00:00 2001
From: Alexander Korotkov <[email protected]>
Date: Tue, 7 Jul 2026 17:32:47 +0300
Subject: [PATCH v1] Move WAIT_FOR_WAL_* wait events from Client to IPC class
WAIT_FOR_WAL_FLUSH, WAIT_FOR_WAL_REPLAY, and WAIT_FOR_WAL_WRITE were
placed in the WaitEventClient class. But WaitEventClient is about
waiting for a socket to become readable or writable, while these events
have other delay sources as well: local fsync and local replay, which
may be disk- or CPU-bound. WaitEventIPC is a better fit, so move them
there.
Reported-by: Noah Misch <[email protected]>
Discussion: https://postgr.es/m/[email protected]
---
src/backend/utils/activity/wait_event_names.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/backend/utils/activity/wait_event_names.txt b/src/backend/utils/activity/wait_event_names.txt
index 560659f9568..1016502d042 100644
--- a/src/backend/utils/activity/wait_event_names.txt
+++ b/src/backend/utils/activity/wait_event_names.txt
@@ -89,9 +89,6 @@ LIBPQWALRECEIVER_CONNECT "Waiting in WAL receiver to establish connection to rem
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 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."
@@ -162,6 +159,9 @@ REPLICATION_SLOT_DROP "Waiting for a replication slot to become inactive so it c
RESTORE_COMMAND "Waiting for <xref linkend="guc-restore-command"/> to complete."
SAFE_SNAPSHOT "Waiting to obtain a valid snapshot for a <literal>READ ONLY DEFERRABLE</literal> transaction."
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."
WAL_RECEIVER_WAIT_START "Waiting for startup process to send initial data for streaming replication."
WAL_SUMMARY_READY "Waiting for a new WAL summary to be generated."
--
2.50.1 (Apple Git-155)
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: wait_event_type for WAIT FOR LSN
2026-07-06 01:26 wait_event_type for WAIT FOR LSN Noah Misch <[email protected]>
2026-07-06 05:41 ` Re: wait_event_type for WAIT FOR LSN Xuneng Zhou <[email protected]>
2026-07-06 20:29 ` Re: wait_event_type for WAIT FOR LSN Noah Misch <[email protected]>
2026-07-07 14:08 ` Re: wait_event_type for WAIT FOR LSN Xuneng Zhou <[email protected]>
2026-07-07 14:38 ` Re: wait_event_type for WAIT FOR LSN Alexander Korotkov <[email protected]>
@ 2026-07-08 00:19 ` Alexander Korotkov <[email protected]>
2026-07-08 05:19 ` Re: wait_event_type for WAIT FOR LSN Xuneng Zhou <[email protected]>
0 siblings, 1 reply; 7+ messages in thread
From: Alexander Korotkov @ 2026-07-08 00:19 UTC (permalink / raw)
To: Xuneng Zhou <[email protected]>; +Cc: Noah Misch <[email protected]>; pgsql-hackers
On Tue, Jul 7, 2026 at 5:38 PM Alexander Korotkov <[email protected]> wrote:
> On Tue, Jul 7, 2026 at 5:08 PM Xuneng Zhou <[email protected]> wrote:
> >
> > On Tue, Jul 7, 2026 at 4:29 AM Noah Misch <[email protected]> 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 <[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.
> >
> > Thanks for clarification. I'm also ok with the status quo.
>
> Thanks to Noah for raising this. Thanks to Xuneng for the feedback.
>
> OK, let's leave WAIT_FOR_STANDBY_CONFIRMATION as is, but move
> WAIT_FOR_WAL_* to WaitEventIPC. The patch is attached. I'm going to
> push it if no objections.
Added "Backpatch-through: 19" line to the commit message.
------
Regards,
Alexander Korotkov
Supabase
Attachments:
[application/octet-stream] v2-0001-Move-WAIT_FOR_WAL_-wait-events-from-Client-to-IPC.patch (2.7K, ../../CAPpHfdtjg5y36MNa1vT5x+uMtgEwr4_esHiM4aaOJ8kKLerHAA@mail.gmail.com/2-v2-0001-Move-WAIT_FOR_WAL_-wait-events-from-Client-to-IPC.patch)
download | inline diff:
From 85caff7bccfcef5f8140f29fff7f8b988f8d92a4 Mon Sep 17 00:00:00 2001
From: Alexander Korotkov <[email protected]>
Date: Tue, 7 Jul 2026 17:32:47 +0300
Subject: [PATCH v2] Move WAIT_FOR_WAL_* wait events from Client to IPC class
WAIT_FOR_WAL_FLUSH, WAIT_FOR_WAL_REPLAY, and WAIT_FOR_WAL_WRITE were
placed in the WaitEventClient class. But WaitEventClient is about
waiting for a socket to become readable or writable, while these events
have other delay sources as well: local fsync and local replay, which
may be disk- or CPU-bound. WaitEventIPC is a better fit, so move them
there.
Reported-by: Noah Misch <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 19
---
src/backend/utils/activity/wait_event_names.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/backend/utils/activity/wait_event_names.txt b/src/backend/utils/activity/wait_event_names.txt
index 560659f9568..1016502d042 100644
--- a/src/backend/utils/activity/wait_event_names.txt
+++ b/src/backend/utils/activity/wait_event_names.txt
@@ -89,9 +89,6 @@ LIBPQWALRECEIVER_CONNECT "Waiting in WAL receiver to establish connection to rem
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 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."
@@ -162,6 +159,9 @@ REPLICATION_SLOT_DROP "Waiting for a replication slot to become inactive so it c
RESTORE_COMMAND "Waiting for <xref linkend="guc-restore-command"/> to complete."
SAFE_SNAPSHOT "Waiting to obtain a valid snapshot for a <literal>READ ONLY DEFERRABLE</literal> transaction."
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."
WAL_RECEIVER_WAIT_START "Waiting for startup process to send initial data for streaming replication."
WAL_SUMMARY_READY "Waiting for a new WAL summary to be generated."
--
2.50.1 (Apple Git-155)
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: wait_event_type for WAIT FOR LSN
2026-07-06 01:26 wait_event_type for WAIT FOR LSN Noah Misch <[email protected]>
2026-07-06 05:41 ` Re: wait_event_type for WAIT FOR LSN Xuneng Zhou <[email protected]>
2026-07-06 20:29 ` Re: wait_event_type for WAIT FOR LSN Noah Misch <[email protected]>
2026-07-07 14:08 ` Re: wait_event_type for WAIT FOR LSN Xuneng Zhou <[email protected]>
2026-07-07 14:38 ` Re: wait_event_type for WAIT FOR LSN Alexander Korotkov <[email protected]>
2026-07-08 00:19 ` Re: wait_event_type for WAIT FOR LSN Alexander Korotkov <[email protected]>
@ 2026-07-08 05:19 ` Xuneng Zhou <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Xuneng Zhou @ 2026-07-08 05:19 UTC (permalink / raw)
To: Alexander Korotkov <[email protected]>; +Cc: Noah Misch <[email protected]>; pgsql-hackers
Hi Alexander,
On Wed, Jul 8, 2026 at 8:19 AM Alexander Korotkov <[email protected]> wrote:
>
> On Tue, Jul 7, 2026 at 5:38 PM Alexander Korotkov <[email protected]> wrote:
> > On Tue, Jul 7, 2026 at 5:08 PM Xuneng Zhou <[email protected]> wrote:
> > >
> > > On Tue, Jul 7, 2026 at 4:29 AM Noah Misch <[email protected]> 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 <[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.
> > >
> > > Thanks for clarification. I'm also ok with the status quo.
> >
> > Thanks to Noah for raising this. Thanks to Xuneng for the feedback.
> >
> > OK, let's leave WAIT_FOR_STANDBY_CONFIRMATION as is, but move
> > WAIT_FOR_WAL_* to WaitEventIPC. The patch is attached. I'm going to
> > push it if no objections.
>
> Added "Backpatch-through: 19" line to the commit message.
Thanks for the patch. LGTM.
--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-07-08 05:19 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-07-06 01:26 wait_event_type for WAIT FOR LSN Noah Misch <[email protected]>
2026-07-06 05:41 ` Xuneng Zhou <[email protected]>
2026-07-06 20:29 ` Noah Misch <[email protected]>
2026-07-07 14:08 ` Xuneng Zhou <[email protected]>
2026-07-07 14:38 ` Alexander Korotkov <[email protected]>
2026-07-08 00:19 ` Alexander Korotkov <[email protected]>
2026-07-08 05:19 ` Xuneng Zhou <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox