From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | thomas(dot)munro(at)gmail(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Reducing WaitEventSet syscall churn |
Date: | 2020-03-13 07:21:13 |
Message-ID: | 20200313.162113.33507975146072569.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello.
At Tue, 10 Mar 2020 08:19:24 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
me> I'l continue reviewing in later mail.
me>
me> > 0005: "libpq: Add PQsocketChangeCount to advertise socket changes."
me> ....
At Thu, 27 Feb 2020 12:17:45 +1300, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote
in
> On Sat, Feb 8, 2020 at 10:15 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> 0005: "libpq: Add PQsocketChangeCount to advertise socket changes."
>
> To support a long lived WES, libpq needs a way tell us when the socket
> changes underneath our feet. This is the simplest thing I could think
> of; better ideas welcome.
I think at least windows is the reason for not just detecting the
change of the value of fd. Instead of counting disconnection, we
could use event libpq-event.
QregisterEventProc returns false for all of bad-parameter,
already-registered, out-of-memory and proc-rejection. I don't think it
is usable interface so the attached 0005 patch fixes that. (but I
found it not necessarily needed after making 0007, but I included it
as a proposal separate from this patch set. It's not including the
corresponding doc fix.).
> 0006: "Reuse a WaitEventSet in libpqwalreceiver.c."
>
> Rather than having all users of libpqwalreceiver.c deal with the
> complicated details of wait set management, have libpqwalreceiver
> expose a waiting interface that understands socket changes.
Looks reasonable. The attached 0006 and 0007 are a possible
replacement if we use libpq-event.
> Unfortunately, I couldn't figure out how to use CommonWaitSet for this
> (ie adding and removing sockets to that as required), due to
> complications with the bookkeeping required to provide the fd_closed
> flag to RemoveWaitEvent(). So it creates its own internal long lived
> WaitEventSet.
Agreed since they are used different way. But with the attached closed
connection is marked as wes_socket_position = -1.
> 0007: "Use a WaitEventSet for postgres_fdw."
Continues..
The attached are:
0001-0004 Not changed
0005 Fix interface of PQregisterEventProc
0006 Add new libpq event for this use.
0007 Another version of "0006 Reuse a WaitEventSet in
libpqwalreceiver.c" based on libpq event.
0008-0011 Not changed (old 0007-0010, blindly appended)
passed the regression (includeing TAP recovery test) up to here.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
0001-Don-t-use-EV_CLEAR-for-kqueue-events.patch | text/x-patch | 1.5 KB |
0002-Use-a-long-lived-WaitEventSet-for-WaitLatch.patch | text/x-patch | 6.1 KB |
0003-Use-WaitLatch-for-condition-variables.patch | text/x-patch | 3.0 KB |
0004-Introduce-RemoveWaitEvent.patch | text/x-patch | 10.7 KB |
0005-Fix-interface-of-PQregisterEventProc.patch | text/x-patch | 3.8 KB |
0006-Add-new-libpq-event-PGEVT_CONNDISCONNECTION.patch | text/x-patch | 1.9 KB |
0007-Reuse-a-WaitEventSet-in-libpqwalreceiver.c.patch | text/x-patch | 13.9 KB |
0008-Use-a-WaitEventSet-for-postgres_fdw.patch | text/x-patch | 5.1 KB |
0009-Use-WL_EXIT_ON_PM_DEATH-in-FeBeWaitSet.patch | text/x-patch | 3.1 KB |
0010-Use-FeBeWaitSet-for-walsender.c.patch | text/x-patch | 3.3 KB |
0011-Introduce-a-WaitEventSet-for-the-stats-collector.patch | text/x-patch | 2.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2020-03-13 07:28:20 | Re: BEFORE ROW triggers for partitioned tables |
Previous Message | John Naylor | 2020-03-13 07:13:02 | Re: truncating timestamps on arbitrary intervals |