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

From Ranier Vilela
Subject Re: Improve the granularity of PQsocketPoll's timeout parameter?
Date
Msg-id CAEudQAp2ED9kDs_z8EqTFfJx3DhAVgmJdP2PFc6mLt8ymQ+=-w@mail.gmail.com
Whole thread Raw
In response to Re: Improve the granularity of PQsocketPoll's timeout parameter?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Em qua., 12 de jun. de 2024 às 14:53, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
Robert Haas <robertmhaas@gmail.com> writes:
> 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.

Here's a v2 responding to some of the comments.

* People pushed back against not using "int64", but the difficulty
with that is that we'd have to #include c.h or at least pg_config.h
in libpq-fe.h, and that would be a totally disastrous invasion of
application namespace.  However, I'd forgotten that libpq-fe.h
does include postgres_ext.h, and there's just enough configure
infrastructure behind that to allow defining pg_int64, which indeed
libpq-fe.h is already relying on.  So we can use that.

* I decided to invent a typedef

        typedef pg_int64 PGusec_time_t;
Perhaps pg_timeusec?
I think it combines with PQgetCurrentTimeUSec
 

instead of writing "pg_int64" explicitly everywhere.  This is perhaps
not as useful as it was when I was thinking the definition would be
"long long int", but it still seems to add some readability.  In my
eyes anyway ... anyone think differently?

* I also undid changes like s/end_time/end_time_us/.  I'd done that
mostly to ensure I looked at/fixed every reference to those variables,
but on reflection I don't think it's doing anything for readability.
end_time seems much better to me.
 

* I took Ranier's suggestion to make fast paths for end_time == 0.
I'm not sure this will make any visible performance difference, but
it's simple and shouldn't hurt.  We do have some code paths that use
that behavior.
Thanks.
 

* Ranier also suggested using clock_gettime instead of gettimeofday,
but I see no reason to do that.  libpq already relies on gettimeofday,
but not on clock_gettime, and anyway post-beta1 isn't a great time to
start experimenting with portability-relevant changes.
I agree.
For v18, it would be a case of thinking about not using it anymore
gettimeofday, as it appears to be deprecated. 

best regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: On disable_cost
Next
From: Tom Lane
Date:
Subject: Re: Contributing test cases to improve coverage