public inbox for [email protected]help / color / mirror / Atom feed
wait_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]> 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 05:41 Xuneng Zhou <[email protected]> parent: 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 20:29 Noah Misch <[email protected]> parent: 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-07 14:08 Xuneng Zhou <[email protected]> parent: Noah Misch <[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-07 14:38 Alexander Korotkov <[email protected]> parent: Xuneng Zhou <[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-08 00:19 Alexander Korotkov <[email protected]> parent: Alexander Korotkov <[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-08 05:19 Xuneng Zhou <[email protected]> parent: Alexander Korotkov <[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