On 2020/10/15 16:21, Fujii Masao wrote:
On 2020/10/14 3:34, Tom Lane wrote:
Fujii Masao writes:
On 2020/10/11 9:16, Tom Lane wrote:
Meanwhile, now that I've looked at commit 32a9c0bdf, I'm not very
happy with it:
* The control flow seems rather forced. I think it was designed
on the as
On 2020/10/14 3:34, Tom Lane wrote:
Fujii Masao writes:
On 2020/10/11 9:16, Tom Lane wrote:
Meanwhile, now that I've looked at commit 32a9c0bdf, I'm not very
happy with it:
* The control flow seems rather forced. I think it was designed
on the assumption that reindenting the existing code
Fujii Masao writes:
> On 2020/10/11 9:16, Tom Lane wrote:
>> Meanwhile, now that I've looked at commit 32a9c0bdf, I'm not very
>> happy with it:
>>
>> * The control flow seems rather forced. I think it was designed
>> on the assumption that reindenting the existing code is forbidden.
> Isn't it
On 2020/10/11 9:16, Tom Lane wrote:
Fujii Masao writes:
Therefore, the easy fix is to make libpq mark the connection as
CONNECTION_BAD even in ECONNABORTED, like we do in ECONNRESET.
So in the wake of commit fe27009cb,
Many thanks for the commit fe27009cb !!
this is what lorikeet is do
Fujii Masao writes:
>>> Therefore, the easy fix is to make libpq mark the connection as
>>> CONNECTION_BAD even in ECONNABORTED, like we do in ECONNRESET.
So in the wake of commit fe27009cb, this is what lorikeet is doing:
@@ -9028,9 +9028,7 @@
CALL terminate_backend_and_wait('fdw_retry_check')
I wrote:
> I've not checked your patch in detail.
Bread crumb for the archives: I started a -hackers thread about this:
https://www.postgresql.org/message-id/flat/2621622.1602184554%40sss.pgh.pa.us
regards, tom lane
Fujii Masao writes:
>> Therefore, the easy fix is to make libpq mark the connection as
>> CONNECTION_BAD even in ECONNABORTED, like we do in ECONNRESET.
> Patch attached. This patch also changes errcode_for_socket_access()
> so that it uses ERRCODE_CONNECTION_FAILURE rather than
> ERRCODE_INTERNA
On 2020/10/08 0:48, Fujii Masao wrote:
On 2020/10/07 22:25, Fujii Masao wrote:
On 2020/10/07 12:54, Fujii Masao wrote:
On 2020/10/07 11:13, Michael Paquier wrote:
Hi Fujii-san,
On Tue, Oct 06, 2020 at 01:52:55AM +, Fujii Masao wrote:
postgres_fdw: reestablish new connection if ca
On 2020/10/07 22:25, Fujii Masao wrote:
On 2020/10/07 12:54, Fujii Masao wrote:
On 2020/10/07 11:13, Michael Paquier wrote:
Hi Fujii-san,
On Tue, Oct 06, 2020 at 01:52:55AM +, Fujii Masao wrote:
postgres_fdw: reestablish new connection if cached one is detected as broken.
In postg
On 2020/10/07 12:54, Fujii Masao wrote:
On 2020/10/07 11:13, Michael Paquier wrote:
Hi Fujii-san,
On Tue, Oct 06, 2020 at 01:52:55AM +, Fujii Masao wrote:
postgres_fdw: reestablish new connection if cached one is detected as broken.
In postgres_fdw, once remote connections are establ
On 2020/10/07 11:13, Michael Paquier wrote:
Hi Fujii-san,
On Tue, Oct 06, 2020 at 01:52:55AM +, Fujii Masao wrote:
postgres_fdw: reestablish new connection if cached one is detected as broken.
In postgres_fdw, once remote connections are established, they are cached
and re-used for subs
Hi Fujii-san,
On Tue, Oct 06, 2020 at 01:52:55AM +, Fujii Masao wrote:
> postgres_fdw: reestablish new connection if cached one is detected as broken.
>
> In postgres_fdw, once remote connections are established, they are cached
> and re-used for subsequent queries and transactions. There can
postgres_fdw: reestablish new connection if cached one is detected as broken.
In postgres_fdw, once remote connections are established, they are cached
and re-used for subsequent queries and transactions. There can be some
cases where those cached connections are unavaiable, for example,
by the re
13 matches
Mail list logo
