From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: More parallel pg_dump bogosities |
Date: | 2018-08-28 19:11:46 |
Message-ID: | 11450.1535483506@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
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 |