So while playing with cluster/vac full on shared catalogs I ran into a
small catch-22. If the transient table created by make_new_heap is
marked relisshared, the code complains because that OID is not known
to IsSharedRelation. If it's not marked shared, you run into various
error checks and Asserts that insist that only shared tables should
be in the pg_global tablespace. Obviously we must put the new table
instance into pg_global, so one or the other type of sanity check
is going to have to be relaxed.
On reflection it seems to me that it's most correct to not mark the
transient table shared: it really isn't, because only the local copy
of pg_class knows anything about it. If we were to take out a
shared-namespace lock on it, that lock would conflict against someone
coincidentally using the same OID for similar purposes in a different
database, and there's no need for that.
On the other side, I think that the checking about pg_global was just
introduced to try to catch coding errors that would put a table in the
wrong tablespace. But that code is all long since debugged.
So I'm of the opinion that we need to back off the checks that insist
only shared tables can be in pg_global. We could allow that either
by pushing the checks up a level (eg, from heap_create_with_catalog
to DefineRelation) or by removing them altogether. The latter would
mean that users could create ordinary tables in the pg_global
tablespace. By default, only superusers could, for lack of public usage
permissions on pg_global.
I'm not sure whether allowing that would be good or bad. I see no
obvious killer reason why it'd be bad, but it seems like the kind of
thing we might regret someday. pg_global is in some sense an
implementation artifact, so allowing users to depend on it might be
bad in the long run.
Comments?
regards, tom lane
