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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Tristan Partin <tristan(at)partin(dot)io>, Dominique Devienne <ddevienne(at)gmail(dot)com>
Subject: Re: Improve the granularity of PQsocketPoll's timeout parameter?
Date: 2024-06-12 19:45:19
Message-ID: 1522504.1718221519@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> v3 attached uses pg_usec_time_t, and fixes one brown-paper-bag
> bug the cfbot noticed in v2.

Oh, I just remembered that there's a different bit of
pqConnectDBComplete that we could simplify now:

if (timeout > 0)
{
/*
* Rounding could cause connection to fail unexpectedly quickly;
* to prevent possibly waiting hardly-at-all, insist on at least
* two seconds.
*/
if (timeout < 2)
timeout = 2;
}
else /* negative means 0 */
timeout = 0;

With this infrastructure, there's no longer any need to discriminate
against timeout == 1 second, so we might as well reduce this to

if (timeout < 0)
timeout = 0;

as it's done elsewhere.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2024-06-12 19:48:57 Re: race condition in pg_class
Previous Message Andres Freund 2024-06-12 19:37:46 Re: Proposal for Updating CRC32C with AVX-512 Algorithm.