From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Fuzzy thinking in is_publishable_class
Date: Thu, 9 May 2019 09:30:50 +0200
Message-ID: <e0f42cfb-b88f-2528-302b-ef6b96410d35@2ndquadrant.com> (raw)
In-Reply-To: <29939.1557369425@sss.pgh.pa.us>
References: <15150.1557257111@sss.pgh.pa.us>
<29939.1557369425@sss.pgh.pa.us>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: peter.eisentraut@2ndquadrant.com, tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org
Subject: Re: Fuzzy thinking in is_publishable_class
In-Reply-To: <e0f42cfb-b88f-2528-302b-ef6b96410d35@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox