From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | Zhihong Yu <zyu(at)yugabyte(dot)com>, Alexey Kondratov <a(dot)kondratov(at)postgrespro(dot)ru>, "Hou, Zhijie" <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit |
Date: | 2021-04-01 15:26:06 |
Message-ID: | ec0be852-240f-3a28-0884-24f03fee5e54@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2021/02/22 14:55, Bharath Rupireddy wrote:
> On Thu, Feb 4, 2021 at 9:36 AM Bharath Rupireddy
> <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>>
>> On Wed, Feb 3, 2021 at 4:22 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
>>> Maybe my explanation in the previous email was unclear. What I think is; If the server-level option is explicitly specified, its setting is used whatever GUC is. On the other hand, if the server-level option is NOT specified, GUC setting is used. For example, if we define the server as follows, GUC setting is used because the server-level option is NOT specified.
>>>
>>> CREATE SERVER loopback FOREIGN DATA WRAPPER postgres;
>>>
>>> If we define the server as follows, the server-level setting is used.
>>>
>>> CREATE SERVER loopback FOREIGN DATA WRAPPER postgres OPTIONS (keep_connections 'on');
>>
>> Attaching v20 patch set. Now, server level option if provided
>> overrides the GUC.The GUC will be used only if server level option is
>> not provided. And also, both server level option and GUC are named the
>> same - "keep_connections".
>>
>> Please have a look.
>
> Attaching v21 patch set, rebased onto the latest master.
I agree to add the server-level option. But I'm still not sure if it's good idea to also expose that option as GUC. Isn't the server-level option enough for most cases?
Also it's strange to expose only this option as GUC while there are other many postgres_fdw options?
With v21-002 patch, even when keep_connections GUC is disabled, the existing open connections are not close immediately. Only connections used in the transaction are closed at the end of that transaction. That is, the existing connections that no transactions use will never be closed. I'm not sure if this behavior is intuitive for users.
Therefore for now I'm thinking to support the server-level option at first... Then if we find it's not enough for most cases in practice, I'd like to consider to expose postgres_fdw options including keep_connections as GUC.
Thought?
BTW these patches fail to be applied to the master because of commit 27e1f14563. I updated and simplified the 003 patch. Patch attached.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Attachment | Content-Type | Size |
---|---|---|
v22-0003-postgres_fdw-server-level-option-keep_connection.patch | text/plain | 10.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2021-04-01 15:30:15 | Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? |
Previous Message | Tom Lane | 2021-04-01 15:09:36 | Re: Asynchronous Append on postgres_fdw nodes. |