wait_event_type for WAIT FOR LSN

Hi Noah,

On Mon, Jul 6, 2026 at 9:26 AM 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 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.

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@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 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.

On Tue, Jul 7, 2026 at 4:29 AM Noah Misch <noah@leadboat.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@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 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.

Hi!

On Tue, Jul 7, 2026 at 5:08 PM Xuneng Zhou <xunengzhou@gmail.com> wrote:

On Tue, Jul 7, 2026 at 4:29 AM Noah Misch <noah@leadboat.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@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 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

On Tue, Jul 7, 2026 at 5:38 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:

On Tue, Jul 7, 2026 at 5:08 PM Xuneng Zhou <xunengzhou@gmail.com> wrote:

On Tue, Jul 7, 2026 at 4:29 AM Noah Misch <noah@leadboat.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@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 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

Hi Alexander,

On Wed, Jul 8, 2026 at 8:19 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:

On Tue, Jul 7, 2026 at 5:38 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:

On Tue, Jul 7, 2026 at 5:08 PM Xuneng Zhou <xunengzhou@gmail.com> wrote:

On Tue, Jul 7, 2026 at 4:29 AM Noah Misch <noah@leadboat.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@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 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.