[Postgres-xl-developers] 答复: do we still need storm_catalog?(Internet mail)

jasonysli(李跃森) jasonysli at tencent.com
Thu Jul 6 19:02:32 PDT 2017


Hi,
	As you said, if the schema is not used anywhere, I agree that you remove it. 
    And thank you for push the code rep based on PG10.  We will look into it and check the regress failures.
Regards
jason

-----邮件原件-----
发件人: Postgres-xl-developers [mailto:postgres-xl-developers-bounces at lists.postgres-xl.org] 代表 Tomas Vondra
发送时间: 2017年7月7日 8:45
收件人: postgres-xl-developers at lists.postgres-xl.org
主题: [Postgres-xl-developers] do we still need storm_catalog?(Internet mail)

Hi,

I'm working on resolving the regression failures after pushing XL 10 merge code to master earlier this week. One of the simple failures is in a test at the very end of misc_sanity suite, which checks that they contain pinned objects.

See:

https://git.postgresql.org/gitweb/?p=postgres-xl.git;a=blob;f=src/test/regress/sql/misc_sanity.sql;hb=HEAD#l39

And we now get failures because pg_namespace gets unexpectedly identified as containing unpinned objects, because storm_catalog happens to be the first entry in pg_namespace (lowest OID) and is missing the pg_depend 'pinned' entry (which means we can do 'DROP SCHEMA' on it).

The other pg_namespace entries are considered pinned, as setup_depend() inserts the necessary dependencies. But it's done like this:

     INSERT INTO pg_depend SELECT 0,0,0, tableoid,oid,0, 'p'
     FROM pg_namespace WHERE nspname LIKE 'pg%';

so it simply misses the storm_catalog schema.

Which means there are two simple ways to fix this - we can either rename the schema to something more generic / not referencing StormDB, or change the INSERT to include storm_catalog. I think we've been considering renaming a bunch of things while working on the 9.6 code, so I'm personally leaning towards renaming the catalog to something like pg_cluster_stats or so.

But after looking at the storm_catalog schema a bit more closely, I'm actually wondering if we should remove it entirely.

Firstly, we don't actually create the contents of the schema, because initdb only does set_input/check_input on the file, but does not actually execute it (unlike for example system_views.sql). Which explains why initdb still works, despite storm_catalog.sql still references pg_current_xlog_insert_location() and other functions that got renamed during the 's/xlog/wal/' change.

Secondly, I'm wondering how useful the schema actually is. I don't see it mentioned anywhere in the docs, and it seems to be merely a copy of the other catalogs, filtered to the current database.

Any opinions on this? Barring objections, I'll get rid of the schema.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services _______________________________________________
Postgres-xl-developers mailing list
Postgres-xl-developers at lists.postgres-xl.org
http://lists.postgres-xl.org/listinfo.cgi/postgres-xl-developers-postgres-xl.org



More information about the Postgres-xl-developers mailing list