In 0001-Add-PUBLICATION-catalogs-and-DDL-v16.patch.gz,
+static bool
+is_publishable_class(Oid relid, Form_pg_class reltuple)
+{
+ return reltuple->relkind == RELKIND_RELATION &&
+ !IsCatalogClass(relid, reltuple) &&
+ reltuple->relpersistence == RELPERSISTENCE_PERMANENT &&
+ /* XXX needed to exclude information_schema tables */
+ relid >= FirstNormalObjectId;
+}
I don't think the XXX part is necessary, because IsCatalogClass()
already checks for the same thing. (The whole thing is a bit bogus
anyway, because you can drop and recreate the information schema at run
time without restriction.)
+#define MAX_RELCACHE_INVAL_MSGS 100
+ List *relids = GetPublicationRelations(HeapTupleGetOid(tup));
+
+ /*
+ * We don't want to send too many individual messages, at some point
+ * it's cheaper to just reset whole relcache.
+ *
+ * XXX: the MAX_RELCACHE_INVAL_MSGS was picked arbitrarily, maybe
+ * there is better limit.
+ */
+ if (list_length(relids) < MAX_RELCACHE_INVAL_MSGS)
Do we have more data on this? There are people running with 100000
tables, and changing a publication with a 1000 tables would blow all
that away?
Maybe at least it should be set relative to INITRELCACHESIZE (400) to
tie things together a bit?
Update the documentation of SharedInvalCatalogMsg in sinval.h for the
"all relations" case. (Maybe look around the whole file to make sure
comments are still valid.)
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
