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 779126e17bd1cc3ec61924801f80db34efed404c.camel@j-davis.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, 2024-06-10 at 17:39 -0400, Tom Lane wrote:
> What I suggest is that we use int64 microseconds
> since the epoch, which is the same idea as the backend's TimestampTz
> except I think we'd better use the Unix epoch not 2000-01-01.
> Then converting code is just a matter of changing variable types
> and adding some zeroes to constants.

...

> Lastly, we need a way to get current time in this form.  My first
> draft of the attached patch had the callers calling gettimeofday
> and doing arithmetic from that, but it seems a lot better to provide
> a function that just parallels time(2).

I briefly skimmed the thread and didn't find the reason why the API
requires an absolute time.

My expectation would be for the last parameter to be a relative timeout
("wait up to X microseconds"). That avoids the annoyance of creating a
new definition of absolute time and exposing a new function to retrieve
it.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: CheckMyDatabase some error messages in two lines.
Next
From: Tom Lane
Date:
Subject: Re: Improve the granularity of PQsocketPoll's timeout parameter?