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

Hi,

Heh, just discovered
https://www.postgresql.org/message-id/20160921171819.1357.29774%40wrigleys.postgresql.org
from the same reporter, where we went through this before :/


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.


> >> But I wonder why the OpenBSD machines in the buildfarm aren't complaining.
> 
> > Or even why it works on other platforms.
> 
> Indeed.  I've confirmed the bug report on a local OpenBSD 6.4 build
> (clang 6.0.0), and with "make -k" I can see that reindexdb.c fails
> likewise.  But this is unsurprising given that POSIX says that
> FD_SETSIZE is declared by sys/select.h.

Right.


> And I'm not that astonished by it not failing on Linux, either; the
> glibc headers are well known for #including much more than POSIX says
> they must.  But it's surprising and worrisome that none of our other
> buildfarm platforms complained.  Seems like somebody should start
> running an animal with a more modern OpenBSD, at least.

I don't see an easy option for making glibc less aggressive on that
front, unfortunately. And I don't want to start running a vm with
openbsd or such.

I wonder if it'd be worth setting up a buildfarm animal on linux using
musl as the libc, based on a quick look it includes less. Doesn't appear
to find this issue however [1], so it's perhaps not worth it.  It fails
with src/bin/pg_upgrade/file.c including linux/fs.h without a proper
configure check:
#ifdef __linux__
#include <sys/ioctl.h>
#include <linux/fs.h>
#endif

Probably worth fixing, even if it can also fixed by just symlinking
/usr/include/linux into /usr/include/x86_64-linux-musl/ (or whatever is
appropriate for the current platform).


[1] The relevant commit's explanation isn't very helpful:
commit 2555fe1b6da21119f87d407ef3838648d5fd601d
Author: Rich Felker <dalias@aerifal.cx>
Date:   2011-04-10 22:47:43 -0400

    add some ugly legacy type names in sys/types.h (u_char etc.)

diff --git a/include/sys/types.h b/include/sys/types.h
index 216574ad..5c6b2090 100644
--- a/include/sys/types.h
+++ b/include/sys/types.h
@@ -59,6 +59,14 @@ extern "C" {
 
 #ifdef _GNU_SOURCE
 typedef unsigned long caddr_t;
+typedef unsigned char u_char;
+typedef unsigned short u_short, ushort;
+typedef unsigned u_int, uint;
+typedef unsigned long u_long, ulong;
+typedef long long quad_t;
+typedef unsigned long long u_quad_t;
+#include <endian.h>
+#include <sys/select.h>
 #include <sys/sysmacros.h>
 #endif
 


Greetings,

Andres Freund