I wrote:
> I'm strongly tempted to just remove the POLL_UNWANTED business
> altogether, as it seems both pointless and unportable on its face.
> Almost by definition, we can't know what "other" bits a given
> implementation might set.
> I'm not entirely following the point of including POLLRDHUP in
Fabien COELHO writes:
> The patch was not applying cleanly anymore for me, so here is a rebase of
> your latest version.
The cfbot doesn't like that patch, probably because of the Windows newlines.
Here's a version with regular newlines, and some cosmetic cleanup in the
configure infrastructure.
I wrote:
> 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.
To check into my a
"Rady, Doug" 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() ra
The author hasn't replied, but the attached seems to have cured the
bitrot so that it at least applies. Let's see what the cfbot makes of
it and then possibly fix any Windows issues.
The patch was not applying cleanly anymore for me, so here is a rebase of
your latest version.
Morever, IST
On 08/09/2018 05:46 PM, Andrew Dunstan wrote:
On 08/09/2018 12:45 PM, Andrew Dunstan wrote:
On 07/03/2018 07:52 PM, Andrew Dunstan wrote:
On 05/17/2018 01:23 AM, Thomas Munro wrote:
On Tue, Mar 27, 2018 at 9:23 AM, Rady, Doug
wrote:
pgbench11-ppoll-v12.patch
Hi Doug,
FYI this patc
On 08/09/2018 12:45 PM, Andrew Dunstan wrote:
On 07/03/2018 07:52 PM, Andrew Dunstan wrote:
On 05/17/2018 01:23 AM, Thomas Munro wrote:
On Tue, Mar 27, 2018 at 9:23 AM, Rady, Doug
wrote:
pgbench11-ppoll-v12.patch
Hi Doug,
FYI this patch is trying and failing to use ppoll() on Windows:
On 07/03/2018 07:52 PM, Andrew Dunstan wrote:
On 05/17/2018 01:23 AM, Thomas Munro wrote:
On Tue, Mar 27, 2018 at 9:23 AM, Rady, Doug wrote:
pgbench11-ppoll-v12.patch
Hi Doug,
FYI this patch is trying and failing to use ppoll() on Windows:
https://ci.appveyor.com/project/postgresql-cfbo
On 05/17/2018 01:23 AM, Thomas Munro wrote:
On Tue, Mar 27, 2018 at 9:23 AM, Rady, Doug wrote:
pgbench11-ppoll-v12.patch
Hi Doug,
FYI this patch is trying and failing to use ppoll() on Windows:
https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.30
It's still failing
On Tue, Mar 27, 2018 at 9:23 AM, Rady, Doug wrote:
> pgbench11-ppoll-v12.patch
Hi Doug,
FYI this patch is trying and failing to use ppoll() on Windows:
https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.30
--
Thomas Munro
http://www.enterprisedb.com
On Apr 7, 2018, at 12:49 AM, Tom Lane wrote:
> Andres Freund writes:
>> I'm still not particularly happy with this.
>
> I'm a bit confused as to what the point is. It seems unlikely that one
> pgbench process can effectively drive enough backends for select's
> limitations to really be an issu
On 2018-04-06 17:49:19 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I'm still not particularly happy with this.
>
> I'm a bit confused as to what the point is. It seems unlikely that one
> pgbench process can effectively drive enough backends for select's
> limitations to really be an issue
Andres Freund writes:
> I'm still not particularly happy with this.
I'm a bit confused as to what the point is. It seems unlikely that one
pgbench process can effectively drive enough backends for select's
limitations to really be an issue.
regards, tom lane
Hi,
I'm still not particularly happy with this. Checking whether I can
polish it up.
a) the new function names are partially non-descriptive and their
meaning is undocumented. As an extreme example:
- if (!FD_ISSET(sock, &input_mask))
+
Hello Doug,
I've compiled and run with both ppoll & select options without issues.
Two quite minor style comment (at least 2 instances):
Fixed. Fixed. Also fixed issue with 'timeout' not being passed as NULL
when no timeout time.
v12 compiled and tested with both ppoll & select (by forcing
Hello Doug,
Updated the patch to not do the #undef
pgbench11-ppoll-v11.patch attached.
Patch applies. Do not forget to regenerate configure to test...
I've compiled and run with both ppoll & select options without issues.
Two quite minor style comment (at least 2 instances):
if (cond) re
On 2018-03-01 11:30:39 +0100, Fabien COELHO wrote:
>
> > > -#ifdef HAVE_SYS_SELECT_H
> > > +#ifdef PGBENCH_USE_SELECT/* force use of
> > > select(2)? */
> > > +#undef HAVE_PPOLL
> > > +#endif
> > > +#ifdef HAVE_PPOLL
> > > +#include
> > > +#elif defined(HAVE_SYS_SELECT_H)
-#ifdef HAVE_SYS_SELECT_H
+#ifdef PGBENCH_USE_SELECT /* force use of select(2)? */
+#undef HAVE_PPOLL
+#endif
+#ifdef HAVE_PPOLL
+#include
+#elif defined(HAVE_SYS_SELECT_H)
+#define POLL_USING_SELECT
(random thing noticed while going through patches)
It strikes me as a b
On 2018-01-28 23:02:57 +, Rady, Doug wrote:
> diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
> index 31ea6ca06e..689f15a772 100644
> --- a/src/bin/pgbench/pgbench.c
> +++ b/src/bin/pgbench/pgbench.c
> @@ -44,7 +44,13 @@
> #include
> #include
> #include
> -#ifdef HAVE_S
Hello Doug,
I'm not sure why you do the following trick, could you explain?
+#undef USE_SELECT
+#define USE_SELECT
This was due to compiler complaint about USE_SELECT being redefined.
Have replaced that "trick" with a new #define POLL_USING_SELECT which is used
elsewhere in pgb
Hello Doug,
Patch applies, compiles, tests ok.
> [...] Replaced USE_PPOLL with HAVE_PPOLL as having both seems redundant.
I'm okay with that. I'm wondering whether there should be a way to force
using one or the other when both are available. Not sure.
Added option to force use of s
Hello Doug,
This time with the revised patch file: pgbench11-ppoll-v8.patch
Patch applies cleanly. Compiles cleanly and runs fine in both ppoll &
select cases.
I'm okay with having a preferred ppoll implementation because of its improved
capability.
A few minor additional comments/sugges
ISTM that the v7 patch version you sent is identical to v6.
--
Fabien.
Hello Doug,
This version of the patch attempts to address the feedback for the
previous submission on 28-Nov-2017
Please avoid recreating a thread, but rather respond to the previous one,
I missed this post.
The overall function-based implementation with limited ifdefs seems
readable and
Doug,
* Rady, Doug (radyd...@amazon.com) wrote:
> 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.
Looks like this patch had som
[...] Yeah, that sort of style would be OK with me. But I wouldn't
like:
struct blah {
#ifdef FOO
int doohicky;
#else
char *doohicky;
};
Indeed. Me neither.
--
Fabien.
On Wed, Nov 29, 2017 at 8:10 AM, Fabien COELHO wrote:
> My point is consistent with my other advice which is to hide the stuff in
> functions with identical (or compatible) signatures, so that the only place
> where it would differ would be in the functions, where greping would work.
>
> #ifdef U
Hello Robert,
ever is best. Not sure that "pfds" is the right name. If the two variables
means the same thing, they should have the same name, although possibly
different types.
Although I agree with a good bit of what you say here, I don't agree
with that. If the member used by ppoll() (or
On Wed, Nov 29, 2017 at 3:40 AM, Fabien COELHO wrote:
> ever is best. Not sure that "pfds" is the right name. If the two variables
> means the same thing, they should have the same name, although possibly
> different types.
Although I agree with a good bit of what you say here, I don't agree
with
Hello,
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.
I'm fine with allowing more clients through ppoll, as large
multi/many/
On Tue, Nov 28, 2017 at 10:38 AM, Rady, Doug wrote:
> 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.
IIUC, ppoll() is to poll(
Hello Michaël,
Could you rebase the v11 patch?
This patch has been waiting for a rebase for more than three weeks as
of today, I am marking it as returned with feedback. It would be a
good idea to reply to Robert's input in
https://www.postgresql.org/message-id/ca+tgmoyybnv-ddhvpmxlb2nx2sqenj
On Fri, Nov 3, 2017 at 2:29 PM, Fabien COELHO wrote:
> Could you rebase the v11 patch?
This patch has been waiting for a rebase for more than three weeks as
of today, I am marking it as returned with feedback. It would be a
good idea to reply to Robert's input in
https://www.postgresql.org/messag
33 matches
Mail list logo
