On Wed, Jul 29, 2015 at 11:28 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It's possible that the problem here is not so much reliance on
> shared_preload_libraries as it is that there's no provision in
> pg_upgrade for dealing with the need to set it. But one way or
> the other, this is a usability fail.
Andres pretty much put his finger on the problem here when he
mentioned labels on shared objects. You can imagine trying to design
this API so that when someone makes reference to label provider xyzzy
we look for a function with that name that has some magic return type
and call it, similar to what we already do with FDWs and what you
recently implemented for TABLESAMPLE. But if the label is on a shared
object, in which database shall we call that function? Even for
database objects, it won't do at all if the same label provider name
is used to mean different things in different databases.
Speaking as the guy who came up with much of the design for feature
and committed KaiGai's patch implementing it, I have to admit that I
didn't think of what problems this would create for pg_upgrade. It
seemed to me at the time that this really wasn't that different from
something like pg_stat_statements, which also won't work properly
unless loaded via shared_preload_libraries. In retrospect, there is a
difference, which is that if you don't load pg_stat_statements, your
DDL and queries will still execute, but in this case, they won't.
That's definitely raising the table stakes, but I'm not sure what to
do about it. Preserving shared_preload_libraries across pg_upgrade is
a tempting solution, but that isn't guaranteed to solve more problems
than it creates.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company