On Wed, Jul 22, 2015 at 2:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Jul 21, 2015 at 2:27 PM, Andres Freund <andres@anarazel.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