Patch for not going beyond NOFILE system limit

Lists: pgsql-bugs
From: Martin Pitt <martin(at)piware(dot)de>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Patch for not going beyond NOFILE system limit
Date: 2004-05-17 12:24:30
Message-ID: 20040517122429.GA2909@donald.intranet.fbn-dd.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

Hi PostgreSQL developers!

Jacek Drobiecki recently sent me a patch which stops postgresql to
actively violate the system limit of maximum open files
(RLIMIT_NOFILE) in src/backend/storage/file/fd.c, function
count_usable_fds().

This avoids irritating kernel logs (if system overstep violations are
enabled) and also the grsecurity alert when starting PostgreSQL.

Can you please adopt this patch?

Currently the modifications are only enabled when postgresql is
compiled with -DCHECK_RLIMIT_NOFILE. Of course you can also use it
unconditionally.

Thanks for considering and have a nice day!

Martin

--
Martin Pitt Debian GNU/Linux Developer
martin(at)piware(dot)de mpitt(at)debian(dot)org
http://www.piware.de http://www.debian.org

Attachment Content-Type Size
08check_rlimit_nofile text/plain 1.0 KB

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Martin Pitt <martin(at)piware(dot)de>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Patch for not going beyond NOFILE system limit
Date: 2004-05-17 12:42:09
Message-ID: 200405171242.i4HCg9n13540@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs


We have already fixed this in CVS and the fix will be in 7.5:

revision 1.107
date: 2004/02/23 20:45:59; author: tgl; state: Exp; lines: +145 -88
Do a direct probe during postmaster startup to determine the maximum
number of openable files and the number already opened. This eliminates
depending on sysconf(_SC_OPEN_MAX), and allows much saner behavior on
platforms where open-file slots are used up by semaphores.

---------------------------------------------------------------------------

Martin Pitt wrote:
-- Start of PGP signed section.
> Hi PostgreSQL developers!
>
> Jacek Drobiecki recently sent me a patch which stops postgresql to
> actively violate the system limit of maximum open files
> (RLIMIT_NOFILE) in src/backend/storage/file/fd.c, function
> count_usable_fds().
>
> This avoids irritating kernel logs (if system overstep violations are
> enabled) and also the grsecurity alert when starting PostgreSQL.
>
> Can you please adopt this patch?
>
> Currently the modifications are only enabled when postgresql is
> compiled with -DCHECK_RLIMIT_NOFILE. Of course you can also use it
> unconditionally.
>
> Thanks for considering and have a nice day!
>
> Martin
>
> --
> Martin Pitt Debian GNU/Linux Developer
> martin(at)piware(dot)de mpitt(at)debian(dot)org
> http://www.piware.de http://www.debian.org

[ Attachment, skipping... ]
-- End of PGP section, PGP failed!

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Martin Pitt <martin(at)piware(dot)de>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Patch for not going beyond NOFILE system limit
Date: 2004-05-19 00:12:39
Message-ID: 9377.1084925559@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> We have already fixed this in CVS and the fix will be in 7.5:

I don't think that the previous changes address what the complainant
seems to really want, viz not even *try* to exceed RLIMIT_NOFILE.

However the patch certainly must be rejected since (a) it appears
unaware of the post-7.4 work in this area, (b) it has not been made
portable (eg, it will fail to compile on machines without getrlimit),
and (c) we do not like patches that add random manual configuration
symbols to the code ... especially undocumented ones.

If this issue seems important to you then please rework the patch to be
up-to-date and properly autoconfiscated, and resubmit.

regards, tom lane