Re: BUG #15964: vacuumdb.c:187:10: error: use of undeclaredidentifier '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@anarazel.de> writes:
> > > On 2019-08-17 16:31:01 -0400, Tom Lane wrote:
> > >> PG Bug reporting form <noreply@postgresql.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@alvh.no-ip.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