Search Postgresql Archives

Re: libpq v17 PQsocketPoll timeout is not granular enough

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 11, 2024 at 2:36 AM Dominique Devienne <ddevienne@xxxxxxxxx> 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.






[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux