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

From Jeff Davis
Subject Re: Improve the granularity of PQsocketPoll's timeout parameter?
Date
Msg-id 9642de7b315640ece27fe7cb72a9d90dec707813.camel@j-davis.com
Whole thread Raw
In response to Re: 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, 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




pgsql-hackers by date:

Previous
From: Amul Sul
Date:
Subject: Re: Logical Replication of sequences
Next
From: Michael Paquier
Date:
Subject: Re: race condition in pg_class