From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
        Alexander Korotkov <a.korotkov@postgrespro.ru>,
        Thomas Munro <tmunro@postgresql.org>,
        pgsql-committers <pgsql-committers@lists.postgresql.org>
Subject: Re: pgsql: Add kqueue(2) support to the WaitEventSet API.
In-reply-to: 
 <CA+hUKGLEAi_QHzuW=jQeHiO3jfjmMec6jvFWTOhXhQiMO-G7hQ@mail.gmail.com>
References: 
 <CA+hUKGKhAxJ8V8RVwCo6zJaeVrdOG1kFBHGZOOjf6DzW_omeMA@mail.gmail.com>
 <20200316203040.GA4019@alvherre.pgsql>
 <CA+hUKGKsTnvROYqx4hUjGpwvCTYi+=+da7sTPCw2Mf2Yxfdi4Q@mail.gmail.com>
 <CA+hUKGLEAi_QHzuW=jQeHiO3jfjmMec6jvFWTOhXhQiMO-G7hQ@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Wed, 18 Mar 2020 13:07:10 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <27778.1585421003.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 28 Mar 2020 14:43:23 -0400
Message-ID: <27779.1585421003@sss.pgh.pa.us>
Precedence: bulk

Thomas Munro <thomas.munro@gmail.com> writes:
> Pushed.

prairiedog just turned up a different issue in this area [1].
I wondered why it hadn't reported in for awhile, and upon
investigation I found that the test run was stuck in the
final pg_dump step of the pg_upgrade test.  pg_dump itself
was waiting for a query result, while the connected backend
was sitting here:

(gdb) bt
#0  0x9002ec88 in kevent ()
#1  0x0039cff8 in WaitEventSetWait (set=3D0x20c502c, timeout=3D-1, occurre=
d_events=3D0xbfffdd4c, nevents=3D1, wait_event_info=3D100663296) at latch.=
c:1443
#2  0x00261d98 in secure_read (port=3D0x2401ba0, ptr=3D0x713558, len=3D819=
2) at be-secure.c:184
#3  0x00269d34 in pq_recvbuf () at pqcomm.c:950
#4  0x00269e24 in pq_getbyte () at pqcomm.c:993
#5  0x003cec2c in PostgresMain (argc=3D1, argv=3D0x38060ac, dbname=3D0x20c=
5154 "regression", username=3D0x20c5138 "buildfarm") at postgres.c:337
#6  0x0032de0c in BackendStartup (port=3D0x2401ba0) at postmaster.c:4510
#7  0x0032fcf8 in PostmasterMain (argc=3D1585338749, argv=3D0x5e7e59b9) at=
 postmaster.c:1727
#8  0x0026f32c in main (argc=3D6, argv=3D0x24009b0) at main.c:210

It'd appear that we dropped an input-is-available condition.

Now prairiedog is running a museum-grade macOS release, so
it's hardly impossible that this is a kernel bug not a
Postgres bug.  But we shouldn't jump to that conclusion,
either, given that our kevent support is so new.

			regards, tom lane

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dprairiedog&d=
t=3D2020-03-27%2018%3A55%3A51
The log shows a SIGABRT trap, but that's because I manually did "kill
-ABRT" to unblock the buildfarm animal.