On 2019-05-09 04:37, Tom Lane wrote:
> I tried removing the FirstNormalObjectId check, and found that the
> reason for it seems to be "the subscription/t/004_sync.pl test
> falls over without it". That's because that test supposes that
> the *only* entry in pg_subscription_rel will be for the test table
> that it creates. Without the FirstNormalObjectId check, the
> information_schema relations also show up in pg_subscription_rel,
> confusing the script's simplistic status check.
right
> I'm of two minds what to do about that. One approach is to just
> define a "FOR ALL TABLES" publication as including the information_schema
> tables,
certainly not
> But, if what we want is the definition that "information_schema is
> excluded from publishable tables", I'm not satisfied with this
> implementation of that rule. Dropping/recreating information_schema
> would cause the behavior to change. We could, at the cost of an
> additional syscache lookup, check the name of the schema that a
> potentially publishable table belongs to and exclude information_schema
> by name. I don't have much idea about how performance-critical
> is_publishable_class is, so I don't know how acceptable that seems.
I would classify the tables in information_schema on the side of being a
system catalog, meaning that they are not replicated and they are
covered by whatever REINDEX SYSTEM thinks it should cover.
It would also make sense to integrate both of these concepts more
consistently with the user_catalog_table feature. Perhaps the
information_schema tables could be made user catalogs. Really we should
just have a single flag in pg_class that says "I'm a catalog",
applicable both to built-in catalogs and to user-defined catalogs.
I think we can get rid of the ability to reload the information_schema
after initdb. That was interesting in the early phase of its
development, but now it just creates complications.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services