From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: More parallel pg_dump bogosities
Date: Tue, 28 Aug 2018 18:22:43 -0400
Message-ID: <10817.1535494963@sss.pgh.pa.us> (raw)
In-Reply-To: <20180828193031.ahilzgnpkug6x45c@alvherre.pgsql>
References: <20180828193031.ahilzgnpkug6x45c@alvherre.pgsql>
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2018-Aug-28, Tom Lane wrote:
>> Doesn't pg_backup_archiver.c's identify_locking_dependencies() need to
>> treat POLICY and ROW SECURITY items as requiring exclusive lock on
>> the referenced table? Those commands definitely acquire
>> AccessExclusiveLock in a quick test.
> I hadn't come across this locking dependency before, so it's pretty
> likely that partitioned index attachment has a problem here.
Hm, it looks like
ALTER INDEX public.at_partitioned_a_idx ATTACH PARTITION public.at_part_1_a_idx;
takes these locks:
relation | mode
----------------------+---------------------
at_part_1 | AccessShareLock
at_partitioned | AccessShareLock
at_part_1_a_idx | AccessExclusiveLock
at_partitioned_a_idx | AccessExclusiveLock
I'm not aware of exactly what this does to catalog entries, but is it
*really* safe to have only AccessShareLock on the tables? That sounds
like a bit of wishful thinking :-(.
In any case, the exclusive locks on the indexes are likely sufficient
to block other operations on the tables (maybe leading to deadlocks),
so I'm inclined to think that yeah, parallel restore should refrain
from running this in parallel with other DDL on either table.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, alvherre@2ndquadrant.com, sfrost@snowman.net, pgsql-hackers@lists.postgresql.org
Subject: Re: More parallel pg_dump bogosities
In-Reply-To: <10817.1535494963@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox