Re: [HACKERS] kqueue - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] kqueue
Date
Msg-id 19739.1579713544@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] kqueue  (Matteo Beccati <php@beccati.com>)
List pgsql-hackers
Matteo Beccati <php@beccati.com> writes:
> On 22/01/2020 17:06, Tom Lane wrote:
>> Matteo Beccati <php@beccati.com> writes:
>>> I had a NetBSD 8.0 VM lying around and I gave the patch a spin on latest
>>> master.
>>> With the kqueue patch, a pgbench -c basically hangs the whole postgres
>>> instance. Not sure if it's a kernel issue, HyperVM issue o what, but
>>> when it hangs, I can't even kill -9 the postgres processes or get the VM
>>> to properly shutdown. The same doesn't happen, of course, with vanilla
>>> postgres.

>> I'm a bit confused about what you are testing --- the kqueue patch
>> as per this thread, or that plus the WaitLatch refactorizations in
>> the other thread you point to above?

> my bad, I tested the v14 patch attached to the email.

Thanks for clarifying.

FWIW, I can't replicate the problem here using NetBSD 8.1 amd64
on bare metal.  I tried various pgbench parameters up to "-c 20 -j 20"
(on a 4-cores-plus-hyperthreading CPU), and it seems fine.

One theory is that NetBSD fixed something since 8.0, but I trawled
their 8.1 release notes [1], and the only items mentioning kqueue
or kevent are for fixes in the pty and tun drivers, neither of which
seem relevant.  (But wait ... could your VM setup be dependent on
a tunnel network interface for outside-the-VM connectivity?  Still
hard to see the connection though.)

My guess is that what you're seeing is a VM bug.

            regards, tom lane

[1] https://cdn.netbsd.org/pub/NetBSD/NetBSD-8.1/CHANGES-8.1



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Do we need to handle orphaned prepared transactions in theserver?
Next
From: Tom Lane
Date:
Subject: Re: Do we need to handle orphaned prepared transactions in the server?