Amit Kapila writes:
> I am thinking that for now, we should raise the limit of
> max_files_per_process in the test to something like 35 or 40, so that
> sidewinder passes and unblocks other people who might get blocked due
> to this
That will not fix the problem for FD-per-semaphore platforms.
On Sun, Jan 5, 2020 at 8:00 AM Noah Misch wrote:
>
> On Sat, Jan 04, 2020 at 06:56:48AM +0530, Amit Kapila wrote:
> > 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,
On Sun, Jan 5, 2020 at 8:30 AM Tom Lane wrote:
>
> Noah Misch writes:
>
> > 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.
>
I think we don't have any tests
Noah Misch 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
On Sat, Jan 04, 2020 at 06:56:48AM +0530, Amit Kapila wrote:
> On Sat, Jan 4, 2020 at 6:19 AM Tom Lane wrote:
> > =?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes:
> > > I tried starting it from cron and then I got:
> > > max_safe_fds = 981, usable_fds = 1000, already_open = 9
> >
> > Oh! There we
On Sat, Jan 4, 2020 at 6:19 AM Tom Lane wrote:
>
> =?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= 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
>
=?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= 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. I wonder if that's a cron bug (neglecting
to close its own FDs before forking children) or intentional (maybe
it
=?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes:
> On 2020-01-04 01:15, Tom Lane wrote:
>> Apparently, in the environment of that TAP test, the server has more
>> open FDs at this point than it does when running "normally". I have
>> no idea what the additional FDs might be.
> Well it's running under
On 2020-01-04 01:21, Mikael Kjellström wrote:
Apparently, in the environment of that TAP test, the server has more
open FDs at this point than it does when running "normally". I have
no idea what the additional FDs might be.
Well it's running under cron if that makes a difference and what is
On 2020-01-04 01:15, Tom Lane wrote:
=?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes:
I think Tom Lane found the "problem". It has to do with the semaphores
taking up FD's.
Hm, no, because:
Yes, saw that after I posted my answer.
Sure. I compiled pgsql 12 and this is the complete logfile
=?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes:
> I think Tom Lane found the "problem". It has to do with the semaphores
> taking up FD's.
Hm, no, because:
> Sure. I compiled pgsql 12 and this is the complete logfile after
> starting up the server the first time with log_min_messages=debug2:
>
On 2020-01-03 15:48, Amit Kapila wrote:
On Fri, Jan 3, 2020 at 7:03 PM Amit Kapila wrote:
I debugged on HEAD and found that we are closing all the files (like
postgresql.conf, postgresql.auto.conf, etc.) that got opened before
set_max_safe_fds. I think on HEAD the 3 already opened files are
I wrote:
> Amit Kapila writes:
>> The problem we are seeing on this machine is that I think we have
>> seven files opened before we reach function set_max_safe_fds during
>> startup. Now, it is not clear to me why it is opening extra file(s)
>> during start-up as compare to other machines.
>
Amit Kapila writes:
> On Fri, Jan 3, 2020 at 6:34 PM Mikael Kjellström
> wrote:
>> Why is this machine different from everybody else when it comes to this
>> limit?
> The problem we are seeing on this machine is that I think we have
> seven files opened before we reach function set_max_safe_fds
On Fri, Jan 3, 2020 at 7:03 PM Amit Kapila wrote:
>
> On Fri, Jan 3, 2020 at 6:34 PM Mikael Kjellström
> wrote:
> >
> >
> > On 2020-01-03 13:01, Amit Kapila wrote:
> >
> > > 2020-01-02 19:51:05.687 CET [24138:3] FATAL: insufficient file
> > > descriptors available to start server process
> > >
On Fri, Jan 3, 2020 at 6:34 PM Mikael Kjellström
wrote:
>
>
> On 2020-01-03 13:01, Amit Kapila wrote:
>
> > 2020-01-02 19:51:05.687 CET [24138:3] FATAL: insufficient file
> > descriptors available to start server process
> > 2020-01-02 19:51:05.687 CET [24138:4] DETAIL: System allows 19, we
> >
On 2020-01-03 13:01, Amit Kapila wrote:
2020-01-02 19:51:05.687 CET [24138:3] FATAL: insufficient file
descriptors available to start server process
2020-01-02 19:51:05.687 CET [24138:4] DETAIL: System allows 19, we
need at least 20.
2020-01-02 19:51:05.687 CET [24138:5] LOG: database
After my recent commit d207038053837ae9365df2776371632387f6f655,
sidewinder is failing with error "insufficient file descriptors .." in
test 006_logical_decoding.pl [1]. The detailed failure displays
messages as below:
006_logical_decoding_master.log
2020-01-02 19:51:05.567 CET [26174:3]
18 matches
Mail list logo
