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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, jungleboogie0(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15964: vacuumdb.c:187:10: error: use of undeclared identifier 'FD_SETSIZE'
Date: 2019-08-20 07:18:41
Message-ID: 20190820071841.GF1841@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Aug 19, 2019 at 02:12:51PM +0900, Michael Paquier wrote:
> Thanks. I have somewhat not catched what Andres was suggesting here.
> So attached are two patches:
> - 0001 should take care of the compilation failure, by moving
> FD_SETSIZE into scripts_parallel.c.

I have been able to work on this one more, and applied a fix that
should address the compilation failure. While on it, I have reduced
the maximum number of parallel slots allowed to give some room for
pre-existing fds as pgbench did before moving to its poll()
implementation.

> - 0002 makes vacuumdb and reindexdb fail when trying to assign a
> socket with an unsupported range. Should this bit be backpatched? We
> are doing that for vacuumdb for some time now, and the error is
> confusing so I would prefer fixing it on older branches as well.

For this one, I am still not completely sure which way we would want
to go. The issue exists down to 9.6 for vacuumdb, so could a fix like
the one I previously proposed be acceptable for a back-patch as this
is not worth the complexity? Should we try to move to a poll()-based
implementation like pgbench on HEAD, which most likely would result in
having pgbench also use parallel slots with a bit of refactoring, no?
--
Michael

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2019-08-20 11:55:06 BUG #15968: Create table if not exists throws "relation already exists" while running in parallel transactions
Previous Message Alexander Lakhin 2019-08-20 07:00:01 Re: BUG #15943: Valgrind-detected error in SlruPhysicalWritePage