Re: [PATCH] postgres_fdw extension support - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [PATCH] postgres_fdw extension support
Date
Msg-id 20150722191512.GB27786@alap3.anarazel.de
Whole thread Raw
In response to Re: [PATCH] postgres_fdw extension support  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] postgres_fdw extension support  (Paul Ramsey <pramsey@cleverelephant.ca>)
List pgsql-hackers
On 2015-07-22 14:55:15 -0400, Tom Lane wrote:
> 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.

It doesn't seem that unlikely that somebody does an ALTER SERVER OPTIONS
SET .. to add an extension to be shippable while connections are already
using the fdw. It'll be confusing if some clients are fast and some
others are really slow.

I think we should at least add invalidations for changing server
options. I think adding support for extension upgrades wouldn't hurt
either. Not particularly excited to ALTER EXTENSION ADD, but we could
add it easy enough.

> If we were trying to cache things across more than a connection lifespan,
> the answer might be different.

I think connection poolers defeat that logic more widely tha nwe
sometimes assume.

- Andres



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] postgres_fdw extension support
Next
From: Peter Geoghegan
Date:
Subject: Re: Eliminating CREATE INDEX comparator TID tie-breaker overhead