MIME-Version: 1.0
From: Dominique Devienne <ddevienne@gmail.com>
Date: Mon, 10 Jun 2024 16:36:03 +0200
Message-ID: <CAFCRh-8hf=7V8UoF63aLxSkeFmXX8-1O5tRxHL61Pngb7V9rcw@mail.gmail.com>
Subject: libpq v17 PQsocketPoll timeout is not granular enough
To: pgsql-general@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAFCRh-8hf%3D7V8UoF63aLxSkeFmXX8-1O5tRxHL61Pngb7V9rcw%40mail.gmail.com>
Precedence: bulk

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.

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.

My use case is clients posting "requests" to the "queue" (i.e. a
PostgreSQL table), which trigger NOTIFY messages, waited on by
"servers"; and those servers informing back clients via further
notifications (on per-request channels) about the processing status of
their requests.

In that use case, second-resolution on long-lived servers is OK.
But OTOH, for the client side, waiting 1s or more to know whether a
server picked up their request is "too long / slow". I'd need
millisecond timeouts for that.

The doc for PQsocketPoll() mentions a different use case for that API.
But I think it would a pity if that unreleased API couldn't be made to
accomodate sub-second timeouts and more use-cases, like above.
Especially given that libpq v17 isn't out yet. I may come late to the
game, but hopefully it is not too late.

Thoughts? Thanks, --DD

[1]: https://www.postgresql.org/docs/17/libpq-connect.html#LIBPQ-PQSOCKETPOLL
[2]: https://github.com/postgres/postgres/blob/master/src/interfaces/libpq/fe-misc.c#L1086