Re: BUG #14738: ALTER SERVER for foregin servers not working

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, fcs1(at)poczta(dot)onet(dot)pl, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #14738: ALTER SERVER for foregin servers not working
Date: 2017-07-11 19:39:14
Message-ID: 6234.1499801954@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> writes:
> Horiguchi-san,
> On 2017/07/11 10:28, Kyotaro HORIGUCHI wrote:
>> I faintly recall such discussion was held aroud that time and
>> maybe we concluded that we don't do that but I haven't find such
>> a thread in pgsql-hackers..

> I mentioned it in my reply. Here again:
> https://www.postgresql.org/message-id/20160405.184408.166437663.horiguchi.kyotaro%40lab.ntt.co.jp

The followup discussion noted that that approach was no good because it
would only close connections in the same session that had done the ALTER
SERVER. I think the basic idea of marking postgres_fdw connections as
needing to be remade when next possible is OK, but we have to drive it
off catcache invalidation events, the same as we did in c52d37c8b. An
advantage of that way is we don't need any new hooks in the core code.

Kyotaro-san, are you planning to update your old patch?

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruno Richard 2017-07-11 20:48:11 Re: PostgreSQL hot standby Hangs due to AccessExclusiveLock on pg_attribute or pg_type tables
Previous Message Jeff Janes 2017-07-11 16:39:17 Re: PostgreSQL hot standby Hangs due to AccessExclusiveLock on pg_attribute or pg_type tables

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2017-07-11 20:20:21 Re: why not parallel seq scan for slow functions
Previous Message Dean Rasheed 2017-07-11 19:24:53 Re: Multi column range partition table