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
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. |