Re: pgsql: Add kqueue(2) support to the WaitEventSet API.

Thomas Munro <thomas(dot)munro(at)gmail(dot)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=0x20c502c, timeout=-1, occurred_events=0xbfffdd4c, nevents=1, wait_event_info=100663296) at latch.c:1443
#2 0x00261d98 in secure_read (port=0x2401ba0, ptr=0x713558, len=8192) 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=1, argv=0x38060ac, dbname=0x20c5154 "regression", username=0x20c5138 "buildfarm") at postgres.c:337
#6 0x0032de0c in BackendStartup (port=0x2401ba0) at postmaster.c:4510
#7 0x0032fcf8 in PostmasterMain (argc=1585338749, argv=0x5e7e59b9) at postmaster.c:1727
#8 0x0026f32c in main (argc=6, argv=0x24009b0) 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=prairiedog&dt=2020-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.