Subject: Re: libpq v17 PQsocketPoll timeout is not granular enough

From: Tom Lane <[email-masked]>
Date: Mon, 10 Jun 2024 12:18:19 -0400

Dominique Devienne <[email-masked]> writes:
> 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.
> ...
> 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.

This is an interesting suggestion, but I think yes it's too late.
We're already past beta1 and this'd require some fairly fundamental
rethinking, since there's no easy substitute for type time_t that has
millisecond resolution.  (The callers do want to specify an end time
not a timeout interval, since some of them loop around PQsocketPoll
and don't want the end time to slip.)

I guess conceivably we could use gettimeofday() and struct timeval
instead of time() and time_t, but it'd touch a lot of places in
libpq and it'd make some of the calculations a lot more complex.

Maybe a better idea would be to convert to using our
src/include/portability/instr_time.h abstraction?  But that
would be problematic for outside callers.

In any case this doesn't seem like a sane thing to be redesigning
post-beta.  A few months ago maybe we'd have done it, but ...

			regards, tom lane

---

From: Dominique Devienne <[email-masked]>
Date: Mon, 10 Jun 2024 20:43:28 +0200

Bummer… I didn’t presume to suggest an api before, but simply adding an
extra int with the milliseconds offset from the time_t is simple, and
trivial to plug into the implementation I saw. Callers who don’t care can
simply pass zero. while I could pass a computed time_t and ms offset using
<chrono>. No need for fancy types imho. Aren’t betas precisely for the
purpose of exposing apis to those like myself to vet them? This is also
beta1, I,e, the first one. My €0.02

---

From: Adrian Klaver <[email-masked]>
Date: Mon, 10 Jun 2024 13:13:43 -0700

On 6/10/24 11:43, Dominique Devienne wrote:
> trivial to plug into the implementation I saw. Callers who don’t care 
> can simply pass zero. while I could pass a computed time_t and ms offset 
> using <chrono>. No need for fancy types imho. Aren’t betas precisely for 

https://www.postgresql.org/developer/beta/

"PostgreSQL beta and release candidate releases are pre-release testing 
versions before the community makes a new release generally available. 
They are feature-frozen (i.e. no new features are added), and we release 
these to the public for testing before our final release. PostgreSQL 
beta and release candidate release are not meant for use in production 
systems."

> the purpose of exposing apis to those like myself to vet them? This is 
> also beta1, I,e, the first one. My €0.02
> 

-- 
Adrian Klaver
[email-masked]