On 01/04/17 01:57, Petr Jelinek wrote: > On 01/04/17 01:20, Tom Lane wrote: >> Petr Jelinek <petr.jeli...@2ndquadrant.com> writes: >>> 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). >> >> Hmmm. What the heap_drop_with_catalog call is being applied to is a >> short-lived table that is not pg_class. It happens to own the disk >> storage that used to belong to pg_class, but it is not pg_class; >> in particular it doesn't have the same OID, and it is not what would >> be looked in if someone happened to need to fetch a pg_class row >> at that point. So there's no circularity involved. >> >> On further reflection it seems like you were right, the problem is >> taking a self-exclusive lock on pg_subscription_rel during low-level >> catalog operations. We're going to have to find a way to reduce that >> lock strength, or we're going to have a lot of deadlock problems. >> > > Well we have heavy lock because we were worried about failure scenarios > in our dump upsert in SetSubscriptionRelState which does cache lookup
*dumb (ie, like me ;) ) -- 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
