On Tue, Jul 10, 2001 at 05:06:28PM -0400, Bruce Momjian wrote:
> > Mathijs Brands <[EMAIL PROTECTED]> writes:
> > > OK, I tried using 1024 (and later 128) instead of SOMAXCONN (defined to
> > > be 5 on Solaris) in src/backend/libpq/pqcomm.c and ran a few regression
> > > tests on two different Sparc boxes (Solaris 7 and 8). The regression
> > > test still fails, but for a different reason. The abstime test fails;
> > > not only on Solaris but also on FreeBSD (4.3-RELEASE).
> >
> > The abstime diff is to be expected (if you look closely, the test is
> > comparing 'current' to 'June 30, 2001'. Ooops). If that's the only
> > diff then you are in good shape.
> >
> >
> > Based on this and previous discussions, I am strongly tempted to remove
> > the use of SOMAXCONN and instead use, say,
> >
> > #define PG_SOMAXCONN 1000
> >
> > defined in config.h.in. That would leave room for configure to twiddle
> > it, if that proves necessary. Does anyone know of a platform where this
> > would cause problems? AFAICT, all versions of listen(2) are claimed to
> > be willing to reduce the passed parameter to whatever they can handle.
>
> Could we test SOMAXCONN and set PG_SOMAXCONN to 1000 only if SOMAXCONN
> is less than 1000?
All the OSes we know of fold it to 128, currently. We can jump it
to 10240 now, or later when there are 20GHz CPUs.
If you want to make it more complicated, it would be more useful to
be able to set the value lower for runtime environments where PG is
competing for OS resources with another daemon that deserves higher
priority.
Nathan Myers
[EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
