From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Rady, Doug" <radydoug@amazon.com>
cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
        Robert Haas <robertmhaas@gmail.com>
Subject: Re: PATCH: pgbench - option to build using ppoll() for larger
 connection counts
In-reply-to: <23D017C9-81B7-484D-8490-FD94DEC4DF59@amazon.com>
References: <23D017C9-81B7-484D-8490-FD94DEC4DF59@amazon.com>
Comments: In-reply-to "Rady, Doug" <radydoug@amazon.com>
	message dated "Mon, 22 Jan 2018 08:34:06 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <30723.1537393562.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 19 Sep 2018 17:46:02 -0400
Message-ID: <30724.1537393562@sss.pgh.pa.us>
Precedence: bulk

"Rady, Doug" <radydoug@amazon.com> writes:
> This patch enables building pgbench to use ppoll() instead of select()
> to allow for more than (FD_SETSIZE - 10) connections.  As implemented,
> when using ppoll(), the only connection limitation is system resources.

So ... why exactly is this patch insisting on ppoll() rather than just
plain poll()?  AFAICS, all you're doing with that is being able to
specify the timeout in microsec not millisec, which does not really
justify taking much of a hit in portability, to my mind.

> =E2=80=9C=E2=80=A6 ppoll() is to poll() as pselect() is to select().  Si=
nce the
> existing code uses select(), why not convert to poll() rather than
> ppoll()?=E2=80=9D

A moment's glance at our git history will remind you that we attempted
to start using pselect() last year, and the attempt crashed and burned:


Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_10_BR [64925603c] 2017-04-24 18:29:03 -0400

    Revert "Use pselect(2) not select(2), if available, to wait in postmas=
ter's loop."
    =

    This reverts commit 81069a9efc5a374dd39874a161f456f0fb3afba4.
    =

    Buildfarm results suggest that some platforms have versions of pselect=
(2)
    that are not merely non-atomic, but flat out non-functional.  Revert t=
he
    use-pselect patch to confirm this diagnosis (and exclude the no-SA_RES=
TART
    patch as the source of trouble).  If it's so, we should probably look =
into
    blacklisting specific platforms that have broken pselect.
    =

    Discussion: https://postgr.es/m/9696.1493072081@sss.pgh.pa.us


Now, it might be that ppoll doesn't suffer from as many portability
problems as pselect, but I don't see a good reason to assume that.
So I'd rather see if we can't convert this to use poll(), and thereby
ensure that it works basically everywhere.

			regards, tom lane