On Sat, Jan 4, 2020 at 6:19 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > =?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= <mikael.kjellst...@mksoft.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? 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. You seem to incline towards (b), but I have a few things to say about that. We have another strange failure due to this test on one of Noah's machine, see my email [1]. I have requested Noah for the stack trace [2]. It is not clear to me whether the committed code has any problem or the test has discovered a different problem in v10 specific to that platform. The same test has passed for v11, v12, and HEAD on the same platform. [1] - https://www.postgresql.org/message-id/CAA4eK1LMDx6vK8Kdw8WUeW1MjToN2xVffL2kvtHvZg17%3DY6QQg%40mail.gmail.com [2] - https://www.postgresql.org/message-id/CAA4eK1LJqMuXoCLuxkTr1HidbR8DkgRrVC7jHWDyXT%3DFD2gt6Q%40mail.gmail.com -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com