On 31/03/17 21:00, Tom Lane wrote: > Petr Jelinek <petr.jeli...@2ndquadrant.com> writes: >> On 31/03/17 20:23, Tom Lane wrote: >>> No, the problematic part is that there is any heap_open happening at >>> all. That open could very easily result in a recursive attempt to read >>> pg_class, for example, which is going to be fatal if we're in the midst >>> of vacuum full'ing or reindex'ing pg_class. It's frankly astonishing >>> to me that this patch seems to have survived testing under >>> CLOBBER_CACHE_ALWAYS, because it's only the catalog caches that are >>> preventing such recursive lookups. > >> Hmm okay, so the solution is to either use standard dependency info for >> this so that it's only called for tables that are actually know to be >> subscribed or have some exceptions in the current code to call the >> function only for user catalogs. Any preferences? > > Looking at dependency info isn't going to fix this, it only moves the > unsafe catalog access somewhere else (ie pg_depend instead of > pg_subscription_rel). I suspect the only safe solution is doing an > IsCatalogRelation or similar test pretty early in the logical replication > code paths. >
I don't follow, everything else does dependency info check in this situation, how is this any different? -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, 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