Re: Improve the granularity of PQsocketPoll's timeout parameter?

On Mon, 2024-06-10 at 19:57 -0400, Tom Lane wrote:
> Because a common call pattern is to loop around PQsocketPoll calls.
> In that scenario you generally want to nail down the timeout time
> before starting the loop, not have it silently move forward after
> any random event that breaks the current wait (EINTR for example).
> pqSocketCheck and pqConnectDBComplete both rely on this.

I agree it makes things easier for a caller following that pattern,
because it doesn't need to recalculate the timeout each time through
the loop.

But:

1. If your clock goes backwards, you can end up waiting for an
arbitrarily long time. To prevent that you need to do some
recalculation each time through the loop anyway.

2. Inventing a new absolute time type just for this single purpose
seems strange to me. Would it be useful in other places? Are we going
to define what kinds of operations/transformations are supported?

3. I can't recall another API that uses absolute time for a timeout;
are you aware of a precedent?

Regards,
Jeff Davis