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
|
Список | 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 по дате отправления: