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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers