]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Make pg_restore's identify_locking_dependencies() more bulletproof.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 28 Aug 2018 23:46:59 +0000 (19:46 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 28 Aug 2018 23:46:59 +0000 (19:46 -0400)
commitaac21f11df0dbe6ee32ac8151bd1ea2c7987f683
tree74e958521326385701e93b6380b3d88f5c78fb1f
parent41cfae1f37187ecff15b4eba5b732ba350801228
Make pg_restore's identify_locking_dependencies() more bulletproof.

This function had a blacklist of dump object types that it believed
needed exclusive lock ... but we hadn't maintained that, so that it
was missing ROW SECURITY, POLICY, and INDEX ATTACH items, all of
which need (or should be treated as needing) exclusive lock.

Since the same oversight seems likely in future, let's reverse the
sense of the test so that the code has a whitelist of safe object
types; better to wrongly assume a command can't be run in parallel
than the opposite.  Currently the only POST_DATA object type that's
safe is CREATE INDEX ... and that list hasn't changed in a long time.

Back-patch to 9.5 where RLS came in.

Discussion: https://postgr.es/m/11450.1535483506@sss.pgh.pa.us
src/bin/pg_dump/pg_backup_archiver.c