On Sun, Dec 31, 2017 at 1:51 PM, Stephen Frost <sfrost@snowman.net> wrote:
> The todo entry even talks about why it's difficult to do and what the
> expected way to go about doing it is (that is, connect to each database
> that has objects in the tablespace and query it to find out what's in
> the tablespace). Craig's suggestion is an interesting alternative way
> though and I'm not sure that it'd be all that bad, but it would be
> limited to catalog tables.
I think it'd be pretty bad. There's nothing in the system that
actually guarantees that the system catalog structure matches across
every database. Of course, if you change structural properties, then
the system will probably crash, but attstorage and attacl values could
be different, as could relfilenode, relpages, reltuples,
relallvisible, relfroxenxid, relminmxid, and relacl. I don't think
it's wise to let this work on the theory that none of that stuff
matters. Even if that's true, or can be made true with a crowbar,
it's a fragile assumption that might turn false in the future.
> If we'd extend the system to allow transparent usage of postgres_fdw to
> access other databases which are part of the same cluster, then this
> could end up being much simpler (eg: select * from
> otherdatabase.pg_catalog.pg_class ...).
It would probably be better to use background workers for this than
postgres_fdw to avoid for example making sure you can authenticate,
but even then this is a pretty significant body of work for what I'd
consider a fairly marginal benefit.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
