From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, Francesco Canovai <francesco(dot)canovai(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Supporting TCP_SYNCNT in libpq |
Date: | 2025-03-21 10:04:16 |
Message-ID: | 97ad7af8-505b-4918-8821-5dc97bfdcdc3@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 18.03.25 21:18, Andres Freund wrote:
> On 2025-03-13 09:37:37 +0100, Francesco Canovai wrote:
>> In this scenario, `tcp_user_timeout` could close a connection retrying
>> the SYNs (even though it doesn't seem to do it from the documentation,
>> it works) the parameter will affect the entire connection.
>> `connect_timeout`, doesn't work with `PQconnectPoll`, so it won't
>> prevent the walreceiver from timing out.
>
> Why not implement timeout support for PQconnectPoll?
Yes, that seems better. It is currently documented that this is
intentionally not supported (see just above [0]), but we should find a
way to solve that.
[0]:
https://www.postgresql.org/docs/devel/libpq-connect.html#LIBPQ-PQSOCKETPOLL
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2025-03-21 10:08:03 | Re: Conflict detection for multiple_unique_conflicts in logical replication |
Previous Message | Jim Jones | 2025-03-21 09:47:09 | Re: [PATCH] Add CANONICAL option to xmlserialize |