Re: PATCH: pgbench - option to build using ppoll() for larger connection counts

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, "Rady, Doug" <radydoug(at)amazon(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: PATCH: pgbench - option to build using ppoll() for larger connection counts
Date: 2018-09-22 16:09:40
Message-ID: 27421.1537632580@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> 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 haven't looked at the pgbench changes proper yet, but I did quickly
test building on FreeBSD 11, which has ppoll, and it falls over:

pgbench.c:6080:69: error: use of undeclared identifier 'POLLRDHUP'
...== -1 || (PQsocket(con) >= 0 && !(sa[idx].revents & POLL_UNWANTED)))
^
pgbench.c:6059:24: note: expanded from macro 'POLL_UNWANTED'
#define POLL_UNWANTED (POLLRDHUP|POLLERR|POLLHUP|POLLNVAL)
^
pgbench.c:6085:42: error: use of undeclared identifier 'POLLRDHUP'
errno, sa[idx].fd, (sa[idx].revents & POLL_UNWANTED));
^
pgbench.c:6059:24: note: expanded from macro 'POLL_UNWANTED'
#define POLL_UNWANTED (POLLRDHUP|POLLERR|POLLHUP|POLLNVAL)
^
pgbench.c:6107:19: error: use of undeclared identifier 'POLLRDHUP'
sa[idx].events = POLL_EVENTS;
^
pgbench.c:6057:22: note: expanded from macro 'POLL_EVENTS'
#define POLL_EVENTS (POLLRDHUP|POLLIN|POLLPRI)
^
3 errors generated.
make[3]: *** [<builtin>: pgbench.o] Error 1

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
POLL_EVENTS, either. What's wrong with the traditional solution
of detecting EOF?

regards, tom lane

Attachment Content-Type Size
pgbench-ppoll-16.patch text/x-diff 14.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2018-09-22 16:46:31 testing pg_dump against very old versions
Previous Message Alexander Korotkov 2018-09-22 13:28:21 Re: pg_atomic_exchange_u32() in ProcArrayGroupClearXid()