On 31/03/17 19:35, Tom Lane wrote:
> Masahiko Sawada <sawada.m...@gmail.com> writes:
>> On Fri, Mar 31, 2017 at 9:53 AM, Petr Jelinek
>> <petr.jeli...@2ndquadrant.com> wrote:
>>> On 30/03/17 07:25, Tom Lane wrote:
>>>> I await with interest an explanation of what "VACUUM FULL pg_class" is
>>>> doing trying to acquire ShareRowExclusiveLock on pg_subscription_rel, not
>>>> to mention why a DROP SEQUENCE is holding some fairly strong lock on that
>>>> relation.
>> VACUUM FULL of any table acquires ShareRowExclusiveLock on
>> pg_subscription_rel because when doDeletion removes old heap the
>> RemoveSubscriptionRel is called in heap_drop_with_catalog.
> This seems entirely horrid: it *guarantees* deadlock possibilities.
> And I wonder what happens when I VACUUM FULL pg_subscription_rel
> itself.
> At the very least, it would be a good idea to exclude the system
> catalogs from logical replication, wouldn't it?

They are excluded. It works same way for triggers and many other objects
so I would not say it's horrid.

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. I
think though that it's not needed though given the access patterns
REFRESH and then by tablesync which holds exclusive lock on the table
itself anyway.

  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:

Reply via email to