From: Tom Lane <tgl@sss.pgh.pa.us>
To: Rady, Doug <radydoug@amazon.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: Robert Haas <robertmhaas@gmail.com>
Subject: Re: PATCH: pgbench - option to build using ppoll() for larger connection counts
Date: Wed, 19 Sep 2018 17:46:02 -0400
Message-ID: <30724.1537393562@sss.pgh.pa.us> (raw)
In-Reply-To: <23D017C9-81B7-484D-8490-FD94DEC4DF59@amazon.com>
References: <23D017C9-81B7-484D-8490-FD94DEC4DF59@amazon.com>
"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.
> “… ppoll() is to poll() as pselect() is to select(). Since the
> existing code uses select(), why not convert to poll() rather than
> ppoll()?”
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 postmaster'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 the
use-pselect patch to confirm this diagnosis (and exclude the no-SA_RESTART
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, radydoug@amazon.com, robertmhaas@gmail.com
Subject: Re: PATCH: pgbench - option to build using ppoll() for larger connection counts
In-Reply-To: <30724.1537393562@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox