Re: More parallel pg_dump bogosities

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: More parallel pg_dump bogosities
Дата
Msg-id 10817.1535494963@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: More parallel pg_dump bogosities  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: some pg_dump query code simplification
Следующее
От: Tom Lane
Дата:
Сообщение: Re: some pg_dump query code simplification