Re: Improve the granularity of PQsocketPoll's timeout parameter? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Improve the granularity of PQsocketPoll's timeout parameter?
Date
Msg-id CA+Tgmob3qSOtaEHKsbcyhtuuF6vKN9YNZ_w6Zy__+c4E2OEaMg@mail.gmail.com
Whole thread Raw
In response to Improve the granularity of PQsocketPoll's timeout parameter?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Improve the granularity of PQsocketPoll's timeout parameter?
List pgsql-hackers
On Mon, Jun 10, 2024 at 5:39 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> In [1] Dominique Devienne complained that PQsocketPoll would be
> far more useful to him if it had better-than-one-second timeout
> resolution.  I initially pushed back on that on the grounds that
> post-beta1 is a bit late to be redefining public APIs.  Which it is,
> but if we don't fix it now then we'll be stuck supporting that API
> indefinitely.  And it's not like one-second resolution is great
> for our internal usage either --- for example, I see that psql
> is now doing
>
>                 end_time = time(NULL) + 1;
>                 rc = PQsocketPoll(sock, forRead, !forRead, end_time);

I agree this is not great. I guess I didn't think about it very hard
because, after all, we were just exposing an API that we'd already
been using internally. But I think it's reasonable to adjust the API
to allow for better resolution, as you propose. A second is a very
long amount of time, and it's entirely reasonable for someone to want
better granularity.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Track the amount of time waiting due to cost_delay
Next
From: Robert Haas
Date:
Subject: Re: Track the amount of time waiting due to cost_delay