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 1hz89A-0004dr-8f for pgsql-bugs@arkaria.postgresql.org; Sat, 17 Aug 2019 23:30:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hz898-0005t4-3O for pgsql-bugs@arkaria.postgresql.org; Sat, 17 Aug 2019 23:30:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hz897-0005pT-OY for pgsql-bugs@lists.postgresql.org; Sat, 17 Aug 2019 23:30:05 +0000 Received: from mail-pg1-x544.google.com ([2607:f8b0:4864:20::544]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hz890-0003d1-SN for pgsql-bugs@lists.postgresql.org; Sat, 17 Aug 2019 23:30:05 +0000 Received: by mail-pg1-x544.google.com with SMTP id e11so4785171pga.5 for ; Sat, 17 Aug 2019 16:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:in-reply-to:date:cc:subject:from:to :message-id; bh=gZA4S1P3NrBfzdl1jxLNoDHXpfmCwk06psqX5BSUmk8=; b=nDheic3z0FkJcGBZMOGjcb0/QpJrpcXquRSD45pAF/7ZdlgGoZLVSXGaBNryb73c0b NHSYKFNmFmNv61YR8W9NERWzq/ylMk/4R2fsfZO+0jvXqnJwiKY9n78gkOkB1o/xSHwT ++5lt8d52avPno09pFjlbiFMYLFfZYhFsCm/Mel1KwmxfvHOhAQSYCwIrikqf07ObonV lYhLrTTovY/goIElJuum8KztEemduiW7X2l6ZrqwzA9GDc+2qsmIHPoJPUX11kiX4l3H N+ee/uOeX9cm4+ArJ67UZaq4/wQwYxwkxKLHtWZeF+BZCuORRCBAC8Rq/FEQKv5jolvK jikg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:in-reply-to:date:cc :subject:from:to:message-id; bh=gZA4S1P3NrBfzdl1jxLNoDHXpfmCwk06psqX5BSUmk8=; b=eJQ38L5QRaPaQUJ9kTMtNnSFXGmDYAphjP3dq5L+NHM8x65Dtqpt4TsbcthvXj/5ap UNet0s6D/S0c2Yvk2QvmfHMYKSzHIJCVyca7uswZvfBtJ3njtLPZsOrBDGOjlfe10txb bA1Z5v65IDrcCI8LtJzByjAxQSLngnUrCkl2K0CrKaisfjJUnvTJLEovJCIHLbgGqs9r brwIKDBCQTUIwIrcUeuPOgxO8rIsBOII8TBiqbIPaUH8ekUDiewTW/zCzBFas+1ImzgM 4MShxZRCpNABrIVHgmJpzEB4RuJesmL4hY8Xo1VLLYh+EtGSGm13lnE1r7n3PQqo5h/i 5NsA== X-Gm-Message-State: APjAAAXXCFdtGXqotJov00nuDYItP/BKiInQglm0GOMkxpiSuM+A1esD wTxq4wisoQRwB3gzBzT2/4A= X-Google-Smtp-Source: APXvYqymy/nphem93wVcw4cbld0WegopV7aSsFJUyI8fj5cAe1rBy2SVQe0PYgaZd1SfGWDFdd1h9w== X-Received: by 2002:a65:6294:: with SMTP id f20mr14090272pgv.349.1566084595345; Sat, 17 Aug 2019 16:29:55 -0700 (PDT) Received: from localhost ([2600:8801:980:9cd:82be:70e6:681d:3a63]) by smtp.gmail.com with ESMTPSA id e13sm14834213pfl.130.2019.08.17.16.29.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Aug 2019 16:29:54 -0700 (PDT) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 In-Reply-To: <20190817224142.gq57z3cwt7c76dtk@alap3.anarazel.de> Date: Sat, 17 Aug 2019 16:29:53 -0700 Cc: , , "Michael Paquier" Subject: Re: BUG #15964: vacuumdb.c:187:10: error: use of undeclared identifier 'FD_SETSIZE' From: "jungle boogie" To: "Andres Freund" , "Tom Lane" Message-Id: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sat Aug 17, 2019 at 3:41 PM Andres Freund wrote: > Hi, >=20 > Heh, just discovered > https://www.postgresql.org/message-id/20160921171819.1357.29774%40wrigley= s.postgresql.org > from the same reporter, where we went through this before :/ Oh, wow! Sorry I didn't remember that. Guess I didn't do a good enough job searching through the archives. >=20 >=20 > On 2019-08-17 17:59:05 -0400, Tom Lane wrote: > > Andres Freund writes: > > > On 2019-08-17 16:31:01 -0400, Tom Lane wrote: > > >> PG Bug reporting form writes: > > >>> vacuumdb.c:184:26: error: use of undeclared identifier 'FD_SETSIZE' > >=20 > > >> Hmm, it seems somebody removed the "#include " from > > >> that file, which was a pretty not-bright idea. > >=20 > > > 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 t= han > > > check FD_SETSIZE directly? > >=20 > > Yeah, that would likely be cleaner than just responding to this directl= y. >=20 > I'll go and do that. >=20 >=20 > > >> But I wonder why the OpenBSD machines in the buildfarm aren't compla= ining. > >=20 > > > Or even why it works on other platforms. > >=20 > > 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. >=20 > Right. I noticed all the machines in your buildfarm are running OpenBSD 5.9 from M= arch 2016 and I believe before clang was the default compiler. I'll see what I c= an find on local craigslist for inexpensive amd64 machines and then have it bu= ild Postgres. Thanks for the efforts you two have put into tracking this down.