|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Stephen Frost <sfrost(at)snowman(dot)net>|
|Subject:||Re: More parallel pg_dump bogosities|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
... 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
|Next Message||Andrey Borodin||2018-08-28 19:30:05||Re: Dimension limit in contrib/cube (dump/restore hazard?)|
|Previous Message||Dean Rasheed||2018-08-28 19:05:13||Re: BUG #15307: Low numerical precision of (Co-) Variance|