MIME-Version: 1.0
References: <CAEP4nAymAZP1VEBNoWAQca85ZtU5YxuwS95+Vu+XW+-eMfq_vQ@mail.gmail.com>
 <CA+hUKG+Sm8ZDiyW5Sr-5QZAK377dy=WHoFSU4vu=tgHOqS5JQQ@mail.gmail.com>
 <CAEP4nAxT4hTd8_JmEE_j1udR58xoXVvOWu-jSTUmrz=CMRfUjA@mail.gmail.com> <CA+hUKGLL4Q6Y6BNp2CwpO+0cmbPqwghuOr3w94MtMgnKTdkh4w@mail.gmail.com>
In-Reply-To: <CA+hUKGLL4Q6Y6BNp2CwpO+0cmbPqwghuOr3w94MtMgnKTdkh4w@mail.gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
Date: Sun, 30 Jul 2023 11:33:18 +1200
Message-ID: <CA+hUKGK2eubAdK3TjrbRMf=htWegcL-09EPNh5xJrp6ZGSgPTw@mail.gmail.com>
Subject: Re: buildfarm instance bichir stuck
To: Robins Tharakan <tharakan@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/mixed; boundary="0000000000008428230601a8a186"
Archived-At: <https://www.postgresql.org/message-id/CA%2BhUKGK2eubAdK3TjrbRMf%3DhtWegcL-09EPNh5xJrp6ZGSgPTw%40mail.gmail.com>
Precedence: bulk

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

On Fri, Apr 9, 2021 at 6:11=E2=80=AFPM Thomas Munro <thomas.munro@gmail.com=
> wrote:
> On Wed, Apr 7, 2021 at 7:31 PM Robins Tharakan <tharakan@gmail.com> wrote=
:
> > Correct. This is easily reproducible on this test-instance, so let me k=
now if you want me to test a patch.
>
> From your description it sounds like signals are not arriving at all,
> rather than some more complicated race.  Let's go back to basics...

I was looking into the portability of SIGURG and OOB socket data for
something totally different (hallway track discussion from PGCon,
could we use that for query cancel, like FTP does, instead of opening
another socket?), and lo and behold, someone has figured out a
workaround for this latch problem:

https://github.com/microsoft/WSL/issues/8619

I don't really want to add code to scrape uname() ouput detect
different kernels at runtime as shown there, but it doesn't seem to
make a difference on Linux if we just always do what was suggested.  I
didn't look too hard into whether that is the right place to put the
call, or really understand *why* it works, and since I am not a
Windows user and we don't have a WSL1 CI, I can't confirm that it
works or explore whether there is some other ordering of operations
that would be better but still work, but if that does the trick then
maybe we should just do something like the attached.

Thoughts?

--0000000000008428230601a8a186
Content-Type: text/x-patch; charset="US-ASCII"; 
	name="0001-Work-around-signalfd-oddity-on-WSL1.patch"
Content-Disposition: attachment; 
	filename="0001-Work-around-signalfd-oddity-on-WSL1.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_lkonc9yu0>
X-Attachment-Id: f_lkonc9yu0

RnJvbSA3YzA3N2ZmMmYwZDkyMmEyZDEzOTQ4ZGI4ZDZjMDFlYjc5MWM4M2M2IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBUaG9tYXMgTXVucm8gPHRob21hcy5tdW5yb0BnbWFpbC5jb20+
CkRhdGU6IFN1biwgMzAgSnVsIDIwMjMgMTA6NDM6MjcgKzEyMDAKU3ViamVjdDogW1BBVENIXSBX
b3JrIGFyb3VuZCBzaWduYWxmZCgpIG9kZGl0eSBvbiBXU0wxLgoKSXQncyBub3QgY2xlYXIgd2h5
IHNldHRpbmcgU0lHVVJHJ3MgZGlzcG9zaXRpb24gdG8gU0lHX0RGTCAod2hpY2ggc2hvdWxkCmJl
IG5vIGNoYW5nZSkgYWZmZWN0cyB0aGUgYmVoYXZpb3Igb2YgV1NMMSAob25lIG9mIHRoZSB3YXlz
IHRoYXQgV2luZG93cwpjYW4gcnVuIExpbnV4IHByb2dyYW1zKS4gIEl0J3MgaGFybWxlcyB0byBk
byB0aGF0IG9uIExpbnV4LCBzbyBsZXQncyBhZGQKdGhhdCB3b3JrYXJvdW5kIHRvIGhlbHAgV1NM
MSB1c2Vycy4gIEJhc2VkIG9uIHJlc2VhcmNoIGRvbmUgYnkgIEVsdmlzClByYW5za2V2aWNodXMg
aW4gYSBXU0wgYnVnIHJlcG9ydDoKCmh0dHBzOi8vZ2l0aHViLmNvbS9taWNyb3NvZnQvV1NML2lz
c3Vlcy84NjE5CgpEaXNjdXNzaW9uOiBodHRwczovL3Bvc3Rnci5lcy9tL0NBRVA0bkF5bUFaUDFW
RUJOb1dBUWNhODVadFU1WXh1d1M5NSUyQlZ1JTJCWFclMkItZU1mcV92USU0MG1haWwuZ21haWwu
Y29tCgpkaWZmIC0tZ2l0IGEvc3JjL2JhY2tlbmQvc3RvcmFnZS9pcGMvbGF0Y2guYyBiL3NyYy9i
YWNrZW5kL3N0b3JhZ2UvaXBjL2xhdGNoLmMKaW5kZXggZGI4ODkzODViNy4uMDZkYzdjNTAzYSAx
MDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvc3RvcmFnZS9pcGMvbGF0Y2guYworKysgYi9zcmMvYmFj
a2VuZC9zdG9yYWdlL2lwYy9sYXRjaC5jCkBAIC0zMDcsNiArMzA3LDEyIEBAIEluaXRpYWxpemVM
YXRjaFN1cHBvcnQodm9pZCkKIAlpZiAoc2lnbmFsX2ZkIDwgMCkKIAkJZWxvZyhGQVRBTCwgInNp
Z25hbGZkKCkgZmFpbGVkIik7CiAJUmVzZXJ2ZUV4dGVybmFsRkQoKTsKKworCS8qCisJICogU2V0
dGluZyB0aGlzIHRvIGl0cyBkZWZhdWx0IGRpc3Bvc2l0aW9uIChpZ25vcmVkKSBhcHBlYXJzIHRv
IGJlCisJICogcmVkdW5kYW50LCBidXQgc2VlbXMgdG8gZml4IGEgcHJvYmxlbSB3aXRoIHNpZ25h
bGZkKCkgb24gV1NMMSBrZXJuZWxzLgorCSAqLworCXBxc2lnbmFsKFNJR1VSRywgU0lHX0RGTCk7
CiAjZW5kaWYKIAogI2lmZGVmIFdBSVRfVVNFX0tRVUVVRQotLSAKMi4zOS4yCgo=
--0000000000008428230601a8a186--