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