Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sGnzo-00HOYx-9c for pgsql-general@arkaria.postgresql.org; Mon, 10 Jun 2024 23:00:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sGnzl-00HEZ1-Vw for pgsql-general@arkaria.postgresql.org; Mon, 10 Jun 2024 23:00:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sGnzl-00HEYs-IU for pgsql-general@lists.postgresql.org; Mon, 10 Jun 2024 23:00:10 +0000 Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sGnzj-0010WS-ON for pgsql-general@postgresql.org; Mon, 10 Jun 2024 23:00:09 +0000 Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-52c8342af5eso2062273e87.3 for ; Mon, 10 Jun 2024 16:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718060406; x=1718665206; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UpTFs7PXaXeAhLnu1Ulv87qbmRCWdkr/fymyqV9Oc6s=; b=KtGazC22e9ZdkRAzeimh8xpRtFtaNSGinqKZkzqsKOF5rnGdrcGlINXpwfBMBwB6YN Xc5Mgy3jnbuK7TnNyhzKXJwXpdVK9wkdm5e870pnkYFJ/2igrgOxTzBu1AxfkzFvV67w OP3rWKLTlCexW/6EJ4jnTYSUq9V1gsOoKd3svFhk8WMmOzt2d/S0rT+99QufCM6oPwDA XTdbMVXyJXAtMyNQdzLZ9c54/BakhVG623hcJCBQomEaU0hRvk7OuhfEHIIFXczTNhO8 +3INfpSFuM5gDBe8BaWaQLXgbvx7dR70rV7nwFnJAJFkzx8kb0zYjnAEaGOwtS6cCsXK F65A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718060406; x=1718665206; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UpTFs7PXaXeAhLnu1Ulv87qbmRCWdkr/fymyqV9Oc6s=; b=qf3D+nesxhG8f0MrmOs3c+otXdTm1MQkTYDVJsJhmhtYBb72TDKqUD0XsFDW1OGErg KHXff2VeMGV53FfH1pX95xqJzKoWhhAB9gNZst9wH7cRkCVMfx5hMifdJq8O5koTexj8 7Yv8eamyPA6Y0GIiOVIGME1A0bD7oUdHUGbtIBbaBRqQ2QGtkBXf0TAWbQI4KcjdjhgI hy6zwiutKun7vMKQh9fcof+ybKrdCkMvEynQGwuk3aZ0U7NlQkjchRg88BnFgpo61Bgt kUZn0AcIMY22jyh5+okQWe8u7XRdN0mh6Xg0mqY4v19X/INMcjS7/EHnq2p6owftSOpb sDtw== X-Gm-Message-State: AOJu0Ywf1Ohjxt9cjPsg80ZhkTzAuL3AUpu5t4V5472ojCl3z0zWgnzX HwfLy8W7bJzMxvoUXruSx3ANuIFAI9SlD/2oW/BTyvxa2LJSPdk5ByowSSnaqHWcEyXkLpljXFH zMVeHdkboQVvoY7SgOMFdoe/a9SE= X-Google-Smtp-Source: AGHT+IE2dGNxcz2jmdc4/Hd8kMWovYEK4hMh6sQp6GPFPAG60nxdNcLfMayINEPKXFC3Li6ekBPJxwvyGNdDuZkza1M= X-Received: by 2002:a19:5f59:0:b0:52c:818a:28f0 with SMTP id 2adb3069b0e04-52c818a2a98mr3718284e87.6.1718060405533; Mon, 10 Jun 2024 16:00:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Thomas Munro Date: Tue, 11 Jun 2024 10:59:28 +1200 Message-ID: Subject: Re: libpq v17 PQsocketPoll timeout is not granular enough To: Dominique Devienne Cc: pgsql-general@postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jun 11, 2024 at 2:36=E2=80=AFAM Dominique Devienne wrote: > Hi. I've noticed [that libpq API in v17 beta1][1], and wanted to use > it to replace an existing Boost.ASIO-based async polling of the > connection's socket, waiting for notifications. The use case being > using PostgreSQL LISTEN/NOTIFY for a simple message queue. The code > needs to be cross-platform Windows and Linux. My goal would be to > eliminate that Boost.ASIO dependency for that, to use just libpq. One idea I have wondered about is why you wouldn't just use poll() directly, if you want a facility that works on all known operating systems without extra portability libraries. Windows has WSApoll(), which AFAIK was designed to be Unix-compatible and a drop-in replacement, requiring just a rename but otherwise having the same macros and struct etc. For some period of time, people who had to deal with socket connection events (that includes us) avoided it, with the Curl guys' blog being the most often cited public explanation for why: https://daniel.haxx.se/blog/2012/10/10/wsapoll-is-broken/ However, as far as I know, that was fixed ~4 years ago: https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-ws= apoll "Note As of Windows 10 version 2004, when a TCP socket fails to connect, (POLLHUP \| POLLERR \| POLLWRNORM) is indicated." I wonder if that means that it's now completely usable on all reasonable versions of the OS. I think so? I don't use Windows myself, my interest in this topic is that I have a slow moving background project to figure out how and when to remove all remaining uses of select() from our tree, and this one is on my hit list. > PQsocketPoll() being based on time_t, it has only second resolution, AFAI= K. > Despite the [underlying implementation in fe-misc.c][2] supporting at > least milliseconds. Yeah, that is not nice and your complaint is very reasonable, and we should probably do something like what Tom suggested. Hmm, but if what I speculated above is true, I wonder if the extern function is even worth its bits... but I don't know how to determine that completely.