From: | Dominique Devienne <ddevienne(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Tristan Partin <tristan(at)partin(dot)io>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Improve the granularity of PQsocketPoll's timeout parameter? |
Date: | 2024-06-11 06:55:00 |
Message-ID: | CAFCRh-_MW-uGg7JXb_1FjZO34FzRFxgxCgyOKKm7QW=V8a15DQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 10, 2024 at 11:39 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The next question is how to spell "int64" in libpq-fe.h.
Hi. Out-of-curiosity, I grep'd for it in my 16.1 libpq:
[ddevienne(at)marsu include]$ grep 'long long' *.h
ecpg_config.h:/* Define to 1 if the system has the type `long long int'. */
ecpg_config.h:/* Define to 1 if `long long int' works and is 64 bits. */
pg_config.h:/* The normal alignment of `long long int', in bytes. */
pg_config.h:/* Define to 1 if `long long int' works and is 64 bits. */
pgtypes_interval.h:typedef long long int int64;
And the relevant snippet of pgtypes_interval.h is:
#ifdef HAVE_LONG_INT_64
#ifndef HAVE_INT64
typedef long int int64;
#endif
#elif defined(HAVE_LONG_LONG_INT_64)
#ifndef HAVE_INT64
typedef long long int int64;
#endif
#else
/* neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 */
#error must have a working 64-bit integer datatype
#endif
Given this precedent, can't the same be done?
And if a 64-bit integer is too troublesome, why not just two 32-bit
parameters instead?
Either a (time_t + int usec), microsecond offset, clamped to [0, 1M),
or (int sec + int usec)?
I'm fine with any portable solution that allows sub-second timeouts, TBH.
Just thinking aloud here. Thanks, --DD
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2024-06-11 07:04:33 | Re: 001_rep_changes.pl fails due to publisher stuck on shutdown |
Previous Message | Bertrand Drouvot | 2024-06-11 06:50:19 | Re: Track the amount of time waiting due to cost_delay |