Noah Misch <noah@leadboat.com> writes:
> On Sat, Jan 04, 2020 at 06:56:48AM +0530, Amit Kapila wrote:
>> So, where do we go from here? Shall we try to identify why cron is
>> keeping extra FDs or we assume that we can't predict how many
>> pre-opened files there will be?
> The latter. If it helps, you could add a regress.c function
> leak_fd_until_max_fd_is(integer) so the main part of the test starts from a
> known FD consumption state.
Hmm ... that's an idea, but I'm not sure that even that would get the
job done. By the time we reach any code in regress.c, there would
have been a bunch of catalog accesses, and so a bunch of the open FDs
would be from VFDs that fd.c could close on demand. So you still
wouldn't have a clear idea of how much stress would be needed to get
to an out-of-FDs situation.
Perhaps, on top of this hypothetical regress.c function, you could
add some function in fd.c to force all VFDs closed, and then have
regress.c call that before it leaks a pile of FDs. But now we're
getting mighty far into the weeds, and away from testing anything
that remotely resembles actual production behavior.
> I generally favor keeping the test, but feel free to decide it's too hard.
I remain dubious that it's worth the trouble, or indeed that the test
would prove anything of interest.
regards, tom lane