Subject: wait_event_type for WAIT FOR LSN

From: Noah Misch <[email-masked]>
Date: Sun, 5 Jul 2026 18:26:42 -0700

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.

---

From: Xuneng Zhou <[email-masked]>
Date: Mon, 6 Jul 2026 13:41:35 +0800

Hi Noah,

> I think WAIT_FOR_WAL_* belong in WaitEventIPC.  In the absence of objections,

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.

> on_shmem_exit callback for xlogwait.c would make it harder to miss callers

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.

---

From: Noah Misch <[email-masked]>
Date: Mon, 6 Jul 2026 13:29:42 -0700

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

---

From: Xuneng Zhou <[email-masked]>
Date: Tue, 7 Jul 2026 22:08:00 +0800

> Overall, I lean toward not changing WAIT_FOR_STANDBY_CONFIRMATION.

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

---

From: Alexander Korotkov <[email-masked]>
Date: Tue, 7 Jul 2026 17:38:32 +0300

Hi!

> 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

---

From: Alexander Korotkov <[email-masked]>
Date: Wed, 8 Jul 2026 03:19:40 +0300

> push it if no objections.

Added "Backpatch-through: 19" line to the commit message.

------
Regards,
Alexander Korotkov
Supabase

---

From: Xuneng Zhou <[email-masked]>
Date: Wed, 8 Jul 2026 13:19:20 +0800

Hi Alexander,

> Added "Backpatch-through: 19" line to the commit message.

Thanks for the patch. LGTM.