Re: [PATCH] postgres_fdw extension support

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Paul Ramsey <pramsey(at)cleverelephant(dot)ca>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] postgres_fdw extension support
Date: 2015-07-22 20:51:20
Message-ID: CA+Tgmoaee1m5A+AEDsYwpJ4A78tQmG3eTXO+Bcy7EEZP6UOSVA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 22, 2015 at 2:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Jul 21, 2015 at 2:27 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>>> But I'm not going to complain too loudly if we don't do invalidation.
>
>> Not doing invalidation seems silly to me. But I don't want to bend
>> Paul too far around the axle, either.
>
> Just to be clear here: the case we are concerned about is, given that
> we have determined that function X is or is not a member of one of the
> extensions marked "shippable" for a given connection, is it likely that
> that status will change (while the function continues to exist with
> the same OID) during the lifespan of the connection? If it did change,
> how critical would it be for us to honor the new shippability criterion
> on that connection? My answer to both is "not very". So I'm not excited
> about expending lots of code or cycles to check for such changes.
>
> If we were trying to cache things across more than a connection lifespan,
> the answer might be different.

We've had a few cases like this at EnterpriseDB where we've not done
invalidations in situations like this, and customers have reported
them as bugs. We've also had cases where PostgreSQL doesn't do this
that have been reported to EnterpriseDB as bugs:

http://www.postgresql.org/message-id/CA+TgmoYDf7dkXhKtk7u_YnAfSt47SgK5J8gD8C1JfSiouU194g@mail.gmail.com

If you know what's happening, these kinds of problems are often no big
deal: you just reconnect and it starts working. The problem is that
customers often DON'T know what is happening, leading to a lot of
frustration and head-banging. "Oh, let me see if reconnecting fixes
it" is just not something that tends to occur to people, at least IME.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gurjeet Singh 2015-07-22 20:59:29 Re: ALTER TABLE .. ADD PRIMARY KEY .. USING INDEX has dump-restore hazard
Previous Message Gurjeet Singh 2015-07-22 20:47:09 Re: ALTER TABLE .. ADD PRIMARY KEY .. USING INDEX has dump-restore hazard