Re: BUG #15964: vacuumdb.c:187:10: error: use of undeclared identifier 'FD_SETSIZE'

Hi,

On 2019-08-17 15:41:42 -0700, Andres Freund wrote:
> On 2019-08-17 17:59:05 -0400, Tom Lane wrote:
> > Andres Freund <andres(at)anarazel(dot)de> writes:
> > > On 2019-08-17 16:31:01 -0400, Tom Lane wrote:
> > >> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> > >>> vacuumdb.c:184:26: error: use of undeclared identifier 'FD_SETSIZE'
> >
> > >> Hmm, it seems somebody removed the "#include <sys/select.h>" from
> > >> that file, which was a pretty not-bright idea.
> >
> > > Most of the parallel code was move into bin/scripts/scripts_parallel.c -
> > > but there's still the above error check. Seems like we ought to add a
> > > ParallelSlotsMax() or such, and use that in the error check, rather than
> > > check FD_SETSIZE directly?
> >
> > Yeah, that would likely be cleaner than just responding to this directly.
>
> I'll go and do that.

Hm. This made me think: Why is

if (concurrentCons > FD_SETSIZE - 1)
{
pg_log_error("too many parallel jobs requested (maximum: %d)",
FD_SETSIZE - 1);

a useful test / error message? FD_SETSIZE is about the numerical value
of fds. There will usually be at least three fds open, starting at 0 -
but there easily can be more, depending on what the reindexdb/vacuumdb
caller is doing.

I'm prone to off-by-one errors, but I think this will over-estimate the
number of allowed connections by 1 even if there's just
stdin/stdout/stderr open.

Looks like this has been copied forward from
commit a17923204736d8842eade3517d6a8ee81290fca4

Author: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Date: 2015-01-23 15:02:45 -0300

vacuumdb: enable parallel mode

This mode allows vacuumdb to open several server connections to vacuum
or analyze several tables simultaneously.

Author: Dilip Kumar. Some reworking by Álvaro Herrera
Reviewed by: Jeff Janes, Amit Kapila, Magnus Hagander, Andres Freund

Alvaro, Dilip?

The pre 12 pgbench at least just subtracted 10 from FD_SETSIZE, to make
room for some pre-existing fds.

What is the reason that this doesn't use poll() in the first place? It
surely can't be - as it is the case for pgbench - that the minimum time
resolution is 1ms?

Greetings,

Andres Freund