Re: sidewinder has one failure

From: Noah Misch <noah(at)leadboat(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mikael Kjellström <mikael(dot)kjellstrom(at)mksoft(dot)nu>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: sidewinder has one failure
Date: 2020-01-05 02:30:05
Message-ID: 20200105023005.GA2279856@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jan 04, 2020 at 06:56:48AM +0530, Amit Kapila wrote:
> On Sat, Jan 4, 2020 at 6:19 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > =?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= <mikael(dot)kjellstrom(at)mksoft(dot)nu> writes:
> > > I tried starting it from cron and then I got:
> > > max_safe_fds = 981, usable_fds = 1000, already_open = 9
> >
> > Oh! There we have it then.
> >
>
> Right.
>
> > I wonder if that's a cron bug (neglecting
> > to close its own FDs before forking children) or intentional (maybe
> > it uses those FDs to keep tabs on the children?).
> >
>
> 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.

> In the latter case, we either want to
> (a) tweak the test to raise the value of max_files_per_process, (b)
> remove the test entirely.

I generally favor keeping the test, but feel free to decide it's too hard.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-01-05 03:00:52 Re: sidewinder has one failure
Previous Message Peter Geoghegan 2020-01-05 02:18:51 Re: pgsql: Add basic TAP tests for psql's tab-completion logic.