On 01/04/17 00:52, Tom Lane wrote: > Petr Jelinek <petr.jeli...@2ndquadrant.com> writes: >> On 31/03/17 21:00, Tom Lane wrote: >>> 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? > > What do you mean by "everything else"? The key point here is that > access to the bootstrap catalogs like pg_class and pg_attribute can't > be dependent on accesses to other catalogs, or we get into circularities. > We certainly aren't trying to look in pg_depend when we do a heap_open. > > (Or, if you tell me that we are now because the logical replication > patch added it, I'm going to start agitating for reverting the patch > and sending it back for redesign.)
But the pg_subscription_rel is also not accessed on heap_open, the problematic code is called from heap_drop_with_catalog. And VACUUM FULL pg_class calls heap_drop_with_catalog() when doing the heap swap (and it goes through performDeletion so through dependency info which is what I mean by everything else does this). -- 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
