Re: More parallel pg_dump bogosities

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: More parallel pg_dump bogosities
Дата
Msg-id 11450.1535483506@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: More parallel pg_dump bogosities  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: More parallel pg_dump bogosities  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
... just when you thought it was safe to go back in the water ...

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 haven't looked hard, but I'm suspicious that other recently-added
dump object types may have been missed here too, and even more
suspicious that we'll forget this again in future.  I wonder if we
shouldn't invert the logic, so that instead of a blacklist of object
types that we assume need exclusive lock, we keep a whitelist of
object types that are known not to (which might be just INDEX,
not sure).  That way, we'd at least be failing in a safe direction.

            regards, tom lane


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

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: csv format for psql
Следующее
От: Andrey Borodin
Дата:
Сообщение: Re: Dimension limit in contrib/cube (dump/restore hazard?)