Jelte Fennema writes:
> It seems the man page of TCP_USER_TIMEOUT does not align with
> reality then. When I use it on my local machine it is effectively used
> as a connection timeout too.
Huh, I should have thought to try that. I confirm this behavior
on RHEL8 (kernel 4.18.0). Not the first
It seems the man page of TCP_USER_TIMEOUT does not align with
reality then. When I use it on my local machine it is effectively used
as a connection timeout too. The second command times out after
two seconds:
sudo iptables -A INPUT -p tcp --destination-port 5432 -j DROP
psql 'host=localhost tcp
Jelte Fennema writes:
> Thanks for all the cleanup and adding of windows support. To me it now looks
> good to merge.
I was about to commit this when I started to wonder if it actually does
anything useful. In particular, I read in the Linux tcp(7) man page
TCP_USER_TIMEOUT (since Linux
Thanks for all the cleanup and adding of windows support. To me it now looks
good to merge.
Meanwhile I've created another patch that adds, a non-blocking version of
PQcancel to libpq.
Which doesn't have this problem by design, because it simply reuses the normal
code for
connection establishe
... btw, speaking of signal-safe functions: I am dismayed to
notice that strerror (and strerror_r) are *not* in POSIX's
list of async-signal-safe functions. This is really quite
unsurprising, considering that they are chartered to return
locale-dependent strings. Unless the data has already been
I wrote:
> (The fact that we now have test coverage for PQcancel makes me a lot
> more willing to try this than I might otherwise be. Will be
> interested to see the cfbot's results.)
On closer look, I'm not sure that psql/t/020_cancel.pl is actually doing
anything on Windows; the cfbot's test tr
Jelte Fennema writes:
> Attached are 3 patches that address the feedback from Andres about code
> duplication
> and splitting up commits. I completely removed internal_cancel now, since it
> only had
> one caller at this point.
Here's some cleaned-up versions of 0001 and 0002. I have not bot
Attached are 3 patches that address the feedback from Andres about code
duplication
and splitting up commits. I completely removed internal_cancel now, since it
only had
one caller at this point.
> IMO, this is a new feature not a bug fix
IMO this is definitely a bugfix. Nowhere in the libpq
Andres Freund writes:
> On 2021-12-28 15:49:00 +, Jelte Fennema wrote:
>> Finally, I would love it if once these fixes are merged the would also be
>> backpatched to
>> previous versions of libpq.
> I'm not really convinced this is a good patch to backpatch. There does seem to
> be some pot
Hi,
On 2021-12-28 15:49:00 +, Jelte Fennema wrote:
> The first patch is a cleaned up version of my previous patch. I think I
> addressed
> all feedback on the previous version in that patch (e.g. removed windows
> code,
> fixed formatting).
To me it seems a bit problematic to introduce a d
I was able to spend some time on this again. I attached two patches to this
email:
The first patch is a cleaned up version of my previous patch. I think I
addressed
all feedback on the previous version in that patch (e.g. removed windows code,
fixed formatting).
The second patch is a new one,
> I'd suggest dropping the separate implementation and turning
> PQrequestCancel() into a thin wrapper around PQgetCancel,
> PQcancel, PQfreeCancel.
Fine by me. I didn't want to change behavior of a deprecated
function.
> I find this patch fairly scary, because it's apparently been coded
> with l
Fujii Masao writes:
> Since PQrequestCancel() is marked as deprecated, I don't think that
> we need to add the feature into it.
Not absolutely necessary, agreed, but it looks like it's pretty
easy to make that happen, so why not? I'd suggest dropping the
separate implementation and turning PQreq
On 2021/10/07 4:58, Jelte Fennema wrote:
Ugh forgot to attach the patch. Here it is.
Thanks for working on this patch!
@@ -4546,10 +4684,21 @@ PQrequestCancel(PGconn *conn)
return false;
}
-
- r = internal_cancel(&conn->raddr, conn->be_pid, conn->be_key,
Since PQreques
Ugh forgot to attach the patch. Here it is.
From: Jelte Fennema
Sent: Wednesday, October 6, 2021 21:56
To: Zhihong Yu
Cc: pgsql-hack...@postgresql.org
Subject: Re: [EXTERNAL] Re: PQcancel does not use tcp_user_timeout,
connect_timeout and keepalive settings
We
We actually ran into an issue caused by this in production, where a PQcancel
connection was open on the client for a 2+ days because the server had
restarted at the wrong moment in the cancel handshake. The client was now
indefinitely waiting for the server to send an EOF back, and because keepa
On Thu, Sep 30, 2021 at 7:45 AM Jelte Fennema
wrote:
> The new connection made by PQcancel does not use the tcp_user_timeout,
> connect_timeout or any of the keepalive settings that are provided in the
> connection string. This means that a call to PQcancel can block for a much
> longer time than
The new connection made by PQcancel does not use the tcp_user_timeout,
connect_timeout or any of the keepalive settings that are provided in the
connection string. This means that a call to PQcancel can block for a much
longer time than intended if there are network issues. This can be especiall
18 matches
Mail list logo
