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

From Petr Jelinek
Subject Re: Somebody has not thought through subscription lockingconsiderations
Date
Msg-id dde48621-7e1b-10fc-b162-5efc1922cfd3@2ndquadrant.com
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 locking considerations  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 31/03/17 20:23, Tom Lane wrote:
> Petr Jelinek <petr.jelinek@2ndquadrant.com> writes:
>> On 31/03/17 19:35, Tom Lane wrote:
>>> At the very least, it would be a good idea to exclude the system
>>> catalogs from logical replication, wouldn't it?
> 
>> They are excluded.
> 
> Well, the exclusion is apparently not checked early enough.  I would say
> that touches of system catalogs should never result in any attempts to
> access the logical relation infrastructure, but what we have here is
> such an access.
> 
>> The problematic part is that the pg_subscription_rel manipulation
>> functions acquire ShareRowExclusiveLock and not the usual
>> RowExclusiveLock because there were some worries about concurrency.
> 
> 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?

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: WIP: [[Parallel] Shared] Hash
Next
From: Mike Palmiotto
Date:
Subject: Re: partitioned tables and contrib/sepgsql