MIME-Version: 1.0
References: <20260706012642.f9.noahmisch@microsoft.com>
 <CABPTF7VAubA+b32dnGGwi3rR2DA=8Lyz4R-hOxvuZLCeCTPPYw@mail.gmail.com>
 <20260706202942.97.noahmisch@microsoft.com>
 <CABPTF7WQ1mQ_YC=G+T=oraRKjatH7v8YDaBqYyh-FST05wBtLw@mail.gmail.com>
In-Reply-To: 
 <CABPTF7WQ1mQ_YC=G+T=oraRKjatH7v8YDaBqYyh-FST05wBtLw@mail.gmail.com>
From: Alexander Korotkov <aekorotkov@gmail.com>
Date: Tue, 7 Jul 2026 17:38:32 +0300
Message-ID: 
 <CAPpHfdtF3E5jtWKWUVj+Lm+Jm48_6b=RHtPPJtvFa-Wpr5w2Dg@mail.gmail.com>
Subject: Re: wait_event_type for WAIT FOR LSN
To: Xuneng Zhou <xunengzhou@gmail.com>
Cc: Noah Misch <noah@leadboat.com>, pgsql-hackers@postgresql.org
Content-Type: multipart/mixed; boundary="00000000000010973d0656065948"
Archived-At: 
 <https://www.postgresql.org/message-id/CAPpHfdtF3E5jtWKWUVj%2BLm%2BJm48_6b%3DRHtPPJtvFa-Wpr5w2Dg%40mail.gmail.com>
Precedence: bulk

--00000000000010973d0656065948
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi!

On Tue, Jul 7, 2026 at 5:08=E2=80=AFPM Xuneng Zhou <xunengzhou@gmail.com> w=
rote:
>
> On Tue, Jul 7, 2026 at 4:29=E2=80=AFAM Noah Misch <noah@leadboat.com> wro=
te:
> >
> > On Mon, Jul 06, 2026 at 01:41:35PM +0800, Xuneng Zhou wrote:
> > > On Mon, Jul 6, 2026 at 9:26=E2=80=AFAM 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 n=
ever 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 establi=
sh connection to remote server."
> > > > >  LIBPQWALRECEIVER_RECEIVE     "Waiting in WAL receiver to receive=
 data from remote server."
> > > > >  SSL_OPEN_SERVER      "Waiting for SSL while attempting connectio=
n."
> > > > >  WAIT_FOR_STANDBY_CONFIRMATION        "Waiting for WAL to be rece=
ived and flushed by the physical standby."
> > > > > -WAIT_FOR_WAL_FLUSH   "Waiting for WAL flush to reach a target LS=
N on a primary."
> > > > > +WAIT_FOR_WAL_FLUSH   "Waiting for WAL flush to reach a target LS=
N on a primary or standby."
> > > > >  WAIT_FOR_WAL_REPLAY  "Waiting for WAL replay to reach a target L=
SN on a standby."
> > > > > +WAIT_FOR_WAL_WRITE   "Waiting for WAL write to reach a target LS=
N on a standby."
> > > > >  WAL_SENDER_WAIT_FOR_WAL      "Waiting for WAL to be flushed in W=
AL sender process."
> > > > >  WAL_SENDER_WRITE_DATA        "Waiting for any activity when proc=
essing 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 a=
re just one
> > > > of the ways to be in WAIT_FOR_WAL_*; other delay sources include lo=
cal fsync
> > > > and local replay, which could be disk-bound or CPU-bound.
> > > >
> > > > I think WAIT_FOR_WAL_* belong in WaitEventIPC.  In the absence of o=
bjections,
> > > > 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 WaitEv=
entIPC:
> >
> > - 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, s=
ince it
> >   impedes comparing waits across versions.
> > - The condition variable is set based on a socket read, and it's fair t=
o treat
> >   the condition variable layer as an implementation detail of little co=
ncern
> >   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

--00000000000010973d0656065948
Content-Type: application/octet-stream;
	name="v1-0001-Move-WAIT_FOR_WAL_-wait-events-from-Client-to-IPC.patch"
Content-Disposition: attachment;
	filename="v1-0001-Move-WAIT_FOR_WAL_-wait-events-from-Client-to-IPC.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mrar58yr0>
X-Attachment-Id: f_mrar58yr0

RnJvbSBjN2Y3ODhhMjFkNjI3ZTM2ZTFiMGVjOWRjNWNhMGE1YTA2YTUyYzE5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBBbGV4YW5kZXIgS29yb3Rrb3YgPGFrb3JvdGtvdkBwb3N0Z3Jl
c3FsLm9yZz4KRGF0ZTogVHVlLCA3IEp1bCAyMDI2IDE3OjMyOjQ3ICswMzAwClN1YmplY3Q6IFtQ
QVRDSCB2MV0gTW92ZSBXQUlUX0ZPUl9XQUxfKiB3YWl0IGV2ZW50cyBmcm9tIENsaWVudCB0byBJ
UEMgY2xhc3MKCldBSVRfRk9SX1dBTF9GTFVTSCwgV0FJVF9GT1JfV0FMX1JFUExBWSwgYW5kIFdB
SVRfRk9SX1dBTF9XUklURSB3ZXJlCnBsYWNlZCBpbiB0aGUgV2FpdEV2ZW50Q2xpZW50IGNsYXNz
LiAgQnV0IFdhaXRFdmVudENsaWVudCBpcyBhYm91dAp3YWl0aW5nIGZvciBhIHNvY2tldCB0byBi
ZWNvbWUgcmVhZGFibGUgb3Igd3JpdGFibGUsIHdoaWxlIHRoZXNlIGV2ZW50cwpoYXZlIG90aGVy
IGRlbGF5IHNvdXJjZXMgYXMgd2VsbDogbG9jYWwgZnN5bmMgYW5kIGxvY2FsIHJlcGxheSwgd2hp
Y2gKbWF5IGJlIGRpc2stIG9yIENQVS1ib3VuZC4gIFdhaXRFdmVudElQQyBpcyBhIGJldHRlciBm
aXQsIHNvIG1vdmUgdGhlbQp0aGVyZS4KClJlcG9ydGVkLWJ5OiBOb2FoIE1pc2NoIDxub2FoQGxl
YWRib2F0LmNvbT4KRGlzY3Vzc2lvbjogaHR0cHM6Ly9wb3N0Z3IuZXMvbS8yMDI2MDcwNjAxMjY0
Mi5mOS5ub2FobWlzY2hAbWljcm9zb2Z0LmNvbQotLS0KIHNyYy9iYWNrZW5kL3V0aWxzL2FjdGl2
aXR5L3dhaXRfZXZlbnRfbmFtZXMudHh0IHwgNiArKystLS0KIDEgZmlsZSBjaGFuZ2VkLCAzIGlu
c2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvc3JjL2JhY2tlbmQvdXRp
bHMvYWN0aXZpdHkvd2FpdF9ldmVudF9uYW1lcy50eHQgYi9zcmMvYmFja2VuZC91dGlscy9hY3Rp
dml0eS93YWl0X2V2ZW50X25hbWVzLnR4dAppbmRleCA1NjA2NTlmOTU2OC4uMTAxNjUwMmQwNDIg
MTAwNjQ0Ci0tLSBhL3NyYy9iYWNrZW5kL3V0aWxzL2FjdGl2aXR5L3dhaXRfZXZlbnRfbmFtZXMu
dHh0CisrKyBiL3NyYy9iYWNrZW5kL3V0aWxzL2FjdGl2aXR5L3dhaXRfZXZlbnRfbmFtZXMudHh0
CkBAIC04OSw5ICs4OSw2IEBAIExJQlBRV0FMUkVDRUlWRVJfQ09OTkVDVAkiV2FpdGluZyBpbiBX
QUwgcmVjZWl2ZXIgdG8gZXN0YWJsaXNoIGNvbm5lY3Rpb24gdG8gcmVtCiBMSUJQUVdBTFJFQ0VJ
VkVSX1JFQ0VJVkUJIldhaXRpbmcgaW4gV0FMIHJlY2VpdmVyIHRvIHJlY2VpdmUgZGF0YSBmcm9t
IHJlbW90ZSBzZXJ2ZXIuIgogU1NMX09QRU5fU0VSVkVSCSJXYWl0aW5nIGZvciBTU0wgd2hpbGUg
YXR0ZW1wdGluZyBjb25uZWN0aW9uLiIKIFdBSVRfRk9SX1NUQU5EQllfQ09ORklSTUFUSU9OCSJX
YWl0aW5nIGZvciBXQUwgdG8gYmUgcmVjZWl2ZWQgYW5kIGZsdXNoZWQgYnkgdGhlIHBoeXNpY2Fs
IHN0YW5kYnkuIgotV0FJVF9GT1JfV0FMX0ZMVVNICSJXYWl0aW5nIGZvciBXQUwgZmx1c2ggdG8g
cmVhY2ggYSB0YXJnZXQgTFNOIG9uIGEgcHJpbWFyeSBvciBzdGFuZGJ5LiIKLVdBSVRfRk9SX1dB
TF9SRVBMQVkJIldhaXRpbmcgZm9yIFdBTCByZXBsYXkgdG8gcmVhY2ggYSB0YXJnZXQgTFNOIG9u
IGEgc3RhbmRieS4iCi1XQUlUX0ZPUl9XQUxfV1JJVEUJIldhaXRpbmcgZm9yIFdBTCB3cml0ZSB0
byByZWFjaCBhIHRhcmdldCBMU04gb24gYSBzdGFuZGJ5LiIKIFdBTF9TRU5ERVJfV0FJVF9GT1Jf
V0FMCSJXYWl0aW5nIGZvciBXQUwgdG8gYmUgZmx1c2hlZCBpbiBXQUwgc2VuZGVyIHByb2Nlc3Mu
IgogV0FMX1NFTkRFUl9XUklURV9EQVRBCSJXYWl0aW5nIGZvciBhbnkgYWN0aXZpdHkgd2hlbiBw
cm9jZXNzaW5nIHJlcGxpZXMgZnJvbSBXQUwgcmVjZWl2ZXIgaW4gV0FMIHNlbmRlciBwcm9jZXNz
LiIKIApAQCAtMTYyLDYgKzE1OSw5IEBAIFJFUExJQ0FUSU9OX1NMT1RfRFJPUAkiV2FpdGluZyBm
b3IgYSByZXBsaWNhdGlvbiBzbG90IHRvIGJlY29tZSBpbmFjdGl2ZSBzbyBpdCBjCiBSRVNUT1JF
X0NPTU1BTkQJIldhaXRpbmcgZm9yIDx4cmVmIGxpbmtlbmQ9Imd1Yy1yZXN0b3JlLWNvbW1hbmQi
Lz4gdG8gY29tcGxldGUuIgogU0FGRV9TTkFQU0hPVAkiV2FpdGluZyB0byBvYnRhaW4gYSB2YWxp
ZCBzbmFwc2hvdCBmb3IgYSA8bGl0ZXJhbD5SRUFEIE9OTFkgREVGRVJSQUJMRTwvbGl0ZXJhbD4g
dHJhbnNhY3Rpb24uIgogU1lOQ19SRVAJIldhaXRpbmcgZm9yIGNvbmZpcm1hdGlvbiBmcm9tIGEg
cmVtb3RlIHNlcnZlciBkdXJpbmcgc3luY2hyb25vdXMgcmVwbGljYXRpb24uIgorV0FJVF9GT1Jf
V0FMX0ZMVVNICSJXYWl0aW5nIGZvciBXQUwgZmx1c2ggdG8gcmVhY2ggYSB0YXJnZXQgTFNOIG9u
IGEgcHJpbWFyeSBvciBzdGFuZGJ5LiIKK1dBSVRfRk9SX1dBTF9SRVBMQVkJIldhaXRpbmcgZm9y
IFdBTCByZXBsYXkgdG8gcmVhY2ggYSB0YXJnZXQgTFNOIG9uIGEgc3RhbmRieS4iCitXQUlUX0ZP
Ul9XQUxfV1JJVEUJIldhaXRpbmcgZm9yIFdBTCB3cml0ZSB0byByZWFjaCBhIHRhcmdldCBMU04g
b24gYSBzdGFuZGJ5LiIKIFdBTF9SRUNFSVZFUl9FWElUCSJXYWl0aW5nIGZvciB0aGUgV0FMIHJl
Y2VpdmVyIHRvIGV4aXQuIgogV0FMX1JFQ0VJVkVSX1dBSVRfU1RBUlQJIldhaXRpbmcgZm9yIHN0
YXJ0dXAgcHJvY2VzcyB0byBzZW5kIGluaXRpYWwgZGF0YSBmb3Igc3RyZWFtaW5nIHJlcGxpY2F0
aW9uLiIKIFdBTF9TVU1NQVJZX1JFQURZCSJXYWl0aW5nIGZvciBhIG5ldyBXQUwgc3VtbWFyeSB0
byBiZSBnZW5lcmF0ZWQuIgotLSAKMi41MC4xIChBcHBsZSBHaXQtMTU1KQoK
--00000000000010973d0656065948--