From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Rémi Zara <remi_zara@mac.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pgsql: Add kqueue(2) support to the WaitEventSet API.
Date: Thu, 20 Feb 2020 23:30:07 -0500
Message-ID: <18091.1582259407@sss.pgh.pa.us> (raw)
In-Reply-To: <6610.1582242943@sss.pgh.pa.us>
References: <E1izCmM-0005pV-Co@gemulon.postgresql.org>
<20200220072435.GM2288@paquier.xyz>
<CA+hUKG+yGQDPdwcH5euDb_pE7OcnbrvGDLoOi2JMaCwj4G+ttg@mail.gmail.com>
<08364CCB-07F5-423E-8CE0-ABF0195C4CA2@mac.com>
<17106.1582224047@sss.pgh.pa.us>
<19710.1582227844@sss.pgh.pa.us>
<20263.1582228617@sss.pgh.pa.us>
<CA+hUKGLh5NSUhPmipF+3n2-y_ncuVWu3DSg7vKhvY2HwxEBiNQ@mail.gmail.com>
<26174.1582236314@sss.pgh.pa.us>
<6610.1582242943@sss.pgh.pa.us>
I wrote:
> Clearly, we gotta do something about that too. Maybe bumping up
> NUM_RESERVED_FDS would be a good idea, but I feel like more-honest
> accounting for permanently-eaten FDs would be a better idea. And
> in any case we can't suppose that there's a fixed upper limit on
> the number of postgres_fdw connections. I'm liking the idea I floated
> earlier of letting postgres_fdw forcibly close the oldest LRU entry.
A late-night glimmer of an idea: suppose we make fd.c keep count,
not just of the open FDs under its control, but also of open FDs
not under its control. The latter count would include the initial
FDs (stdin/stdout/stderr), and FDs allocated by OpenTransientFile
et al, and we could provide functions for other callers to report
that they just allocated or released a FD. So postgres_fdw could
report, when it opens or closes a PGconn, that the count of external
FDs should be increased or decreased. fd.c would then forcibly
close VFDs as needed to keep NUM_RESERVED_FDS worth of slop. We
still need slop, to provide some daylight for code that isn't aware
of this mechanism. But we could certainly get all these known
long-lived FDs to be counted, and that would allow fd.c to reduce
the number of open VFDs enough to ensure that some slop remains.
This idea doesn't fix every possible problem. For instance, if you
have a plperlu function that wants to open a bunch of files, I don't
see any easy way to ensure we release VFDs to make that possible.
But it's sure an improvement on the status quo.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: tgl@sss.pgh.pa.us, thomas.munro@gmail.com, remi_zara@mac.com, michael@paquier.xyz, pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Add kqueue(2) support to the WaitEventSet API.
In-Reply-To: <18091.1582259407@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox