MIME-Version: 1.0
References: <CAFCRh-8hf=7V8UoF63aLxSkeFmXX8-1O5tRxHL61Pngb7V9rcw@mail.gmail.com>
 <CA+hUKGKgvN=jjCcTtfEHiyiWkivgz1POLe2GPbeDPajZGkF_Ew@mail.gmail.com> <927473.1718063365@sss.pgh.pa.us>
In-Reply-To: <927473.1718063365@sss.pgh.pa.us>
From: Francisco Olarte <folarte@peoplecall.com>
Date: Tue, 11 Jun 2024 09:19:02 +0200
Message-ID: <CA+bJJbyvEj3MNniVFwayTUAZK9cche6XqThgqZnhnXex-gf3kA@mail.gmail.com>
Subject: Re: libpq v17 PQsocketPoll timeout is not granular enough
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <thomas.munro@gmail.com>, Dominique Devienne <ddevienne@gmail.com>, 
	pgsql-general@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CA%2BbJJbyvEj3MNniVFwayTUAZK9cche6XqThgqZnhnXex-gf3kA%40mail.gmail.com>
Precedence: bulk

Tom:

On Tue, 11 Jun 2024 at 01:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> I think if we're going to change anything at all here, we should
> define the external API in microseconds not milliseconds.  The lesson
> we need to be taking from this is that system calls come and go,
> but libpq API is forever ;-).  Somebody could conceivably want
> sub-millisecond wait resolution within the lifespan of libpq.

I was thinking on that, but since you need at least 20 bits, so 32,
for microseconds I would suggest nanoseconds, which fit in 32 too.
Sure, nanos seems too much for the current time but it pushes the
future problem further down, nearly forever for comms between
different machines until someone develops FTL networks.

Francisco Olarte.