Re: Somebody has not thought through subscription locking considerations - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Somebody has not thought through subscription locking considerations
Date
Msg-id 11052.1491000757@sss.pgh.pa.us
Whole thread Raw
In response to Re: Somebody has not thought through subscription lockingconsiderations  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Responses Re: Somebody has not thought through subscription lockingconsiderations
List pgsql-hackers
Petr Jelinek <petr.jelinek@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.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Douglas Doole
Date:
Subject: Table collision in join.sql and aggregates.sql
Next
From: Petr Jelinek
Date:
Subject: Re: Somebody has not thought through subscription lockingconsiderations