Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hz5oQ-0000zZ-1g for pgsql-bugs@arkaria.postgresql.org; Sat, 17 Aug 2019 21:00:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hz5oN-0006Ep-Vh for pgsql-bugs@arkaria.postgresql.org; Sat, 17 Aug 2019 21:00:31 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hz5oN-0006D7-JG for pgsql-bugs@lists.postgresql.org; Sat, 17 Aug 2019 21:00:31 +0000 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1hz5oL-0007aj-AB for pgsql-bugs@lists.postgresql.org; Sat, 17 Aug 2019 21:00:30 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 87AC86C7; Sat, 17 Aug 2019 17:00:27 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sat, 17 Aug 2019 17:00:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=SPMvwqJG6NeOAN4IklPNBbGI2N/ yaE5MM7KNtcb5swY=; b=Mnt/z1vpTsMXbXVg/9WkRf5IVQKs6K9SelQL5iVW6b6 2gm+rzK86YQOxVPEVFclCbe9RKMEsJDnMk7kVdjhIN/JHozxJpMEVO+dz51OfsJE xDm/vA4Ujcxr8vytnApYaXEZObK+HJz7eXLkHsGyJKbT6M2LuldMwwYuj/BTbvK6 AFPVtmTDpHituZ8GTKRxcYjrLTwQxdKUYrCVai2q+uBGZZKmSYJn55Og8s2VnWnb C2X1CneKsYBlBlxruBzrqy4K3oMAcHk+GO6JN889Ed47vMP1KjOSs/OsPTW2OKFv 8sMR2EfnnrXZNTvsy3HIzQ/+DWhPpOfS5dAFPnaJO1w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=SPMvwq JG6NeOAN4IklPNBbGI2N/yaE5MM7KNtcb5swY=; b=cus8Ce8hsst6PtHl1iCoN8 DQKUmZKF/ffeAIbi7Kn1LkxmdyFkjw5V//55e0oVrh7GW1b05w8LFlB6bJancycR uwQsw4kSvujnfklI04FYC3QLm9rDXbn1Qllz9lQ2OL5vj1OJuEeGvTe27assyKFV Sy+SIIQt62RQuitwpQEu/3A4I+CYIcEp32w1VeJPgTV8mhaYK9wBgwd+jriuQRmA n8ZmI5ksJsoy86BYbG+Fv5XOJS9/5fD9/YTuI3TRmtrn84TZ70KO/MOKXV+FoqRv MvcgJOloFiLXyOeVTHeWrEIZZkFvqvto9y42+2UqraINmUWkVCDeQOUcUOvyaTsg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudefhedgudehkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehttd ertddttddvnecuhfhrohhmpeetnhgurhgvshcuhfhrvghunhguuceorghnughrvghssegr nhgrrhgriigvlhdruggvqeenucfkphepieejrdduiedtrddvudekrddvfeejnecurfgrrh grmhepmhgrihhlfhhrohhmpegrnhgurhgvshesrghnrghrrgiivghlrdguvgenucevlhhu shhtvghrufhiiigvpedt X-ME-Proxy: Received: from intern.anarazel.de (c-67-160-218-237.hsd1.ca.comcast.net [67.160.218.237]) by mail.messagingengine.com (Postfix) with ESMTPA id 8A3E680062; Sat, 17 Aug 2019 17:00:26 -0400 (EDT) Date: Sat, 17 Aug 2019 14:00:25 -0700 From: Andres Freund To: Tom Lane Cc: jungleboogie0@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #15964: vacuumdb.c:187:10: error: use of undeclared identifier 'FD_SETSIZE' Message-ID: <20190817210025.v4bblh4lhsxajmlj@alap3.anarazel.de> References: <15964-c1753bdfed722e04@postgresql.org> <24757.1566073861@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24757.1566073861@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 2019-08-17 16:31:01 -0400, Tom Lane wrote: > PG Bug reporting form writes: > > I'm trying to compile Postgresql from master on my OpenBSD machine, but I'm > > getting a build failure here: > > vacuumdb.c:184:26: error: use of undeclared identifier 'FD_SETSIZE' > > if (concurrentCons > FD_SETSIZE - 1) > > ^ > > Hmm, it seems somebody removed the "#include " 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? > But I wonder why the OpenBSD machines in the buildfarm aren't complaining. Or even why it works on other platforms. On linux/glibc it looks like sys/select.h is included by sys/types.h under certain conditions: #ifdef __USE_MISC /* In BSD is expected to define BYTE_ORDER. */ # include /* It also defines `fd_set' and the FD_* macros for `select'. */ # include #endif /* Use misc. */ which in turn is included by stddef.h under certain conditions: #if defined __USE_MISC || defined __USE_XOPEN_EXTENDED # include /* we need int32_t... */ stddef.h is included by c.h, so will obviously be included in any of our .c files. _USE_MISC and _XOPEN_SOURCE_EXTENDED are defined by default, unless they're explicitly specified (which we don't). I assume there's some compiler specific going on. Our animals use an old gcc version, whereas Sean's uses a modern clang. Not hard to imagine that the compiler specific bits look different enough to cause such a discrepancy. Greetings, Andres Freund