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.
