Re: libpq v17 PQsocketPoll timeout is not granular enough

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Dominique Devienne <ddevienne(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: libpq v17 PQsocketPoll timeout is not granular enough
Date: 2024-06-10 22:59:28
Message-ID: CA+hUKGKgvN=jjCcTtfEHiyiWkivgz1POLe2GPbeDPajZGkF_Ew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Jun 11, 2024 at 2:36 AM Dominique Devienne <ddevienne(at)gmail(dot)com> wrote:
> Hi. I've noticed [that libpq API in v17 beta1][1], and wanted to use
> it to replace an existing Boost.ASIO-based async polling of the
> connection's socket, waiting for notifications. The use case being
> using PostgreSQL LISTEN/NOTIFY for a simple message queue. The code
> needs to be cross-platform Windows and Linux. My goal would be to
> eliminate that Boost.ASIO dependency for that, to use just libpq.

One idea I have wondered about is why you wouldn't just use poll()
directly, if you want a facility that works on all known operating
systems without extra portability libraries. Windows has WSApoll(),
which AFAIK was designed to be Unix-compatible and a drop-in
replacement, requiring just a rename but otherwise having the same
macros and struct etc.

For some period of time, people who had to deal with socket connection
events (that includes us) avoided it, with the Curl guys' blog being
the most often cited public explanation for why:

https://daniel.haxx.se/blog/2012/10/10/wsapoll-is-broken/

However, as far as I know, that was fixed ~4 years ago:

https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsapoll

"Note As of Windows 10 version 2004, when a TCP socket fails to
connect, (POLLHUP \| POLLERR \| POLLWRNORM) is indicated."

I wonder if that means that it's now completely usable on all
reasonable versions of the OS. I think so? I don't use Windows
myself, my interest in this topic is that I have a slow moving
background project to figure out how and when to remove all remaining
uses of select() from our tree, and this one is on my hit list.

> PQsocketPoll() being based on time_t, it has only second resolution, AFAIK.
> Despite the [underlying implementation in fe-misc.c][2] supporting at
> least milliseconds.

Yeah, that is not nice and your complaint is very reasonable, and we
should probably do something like what Tom suggested.

Hmm, but if what I speculated above is true, I wonder if the extern
function is even worth its bits... but I don't know how to determine
that completely.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2024-06-10 23:03:50 Re: Gaps in PK sequence numbers
Previous Message Rich Shepard 2024-06-10 22:57:26 Gaps in PK sequence numbers