Horton

Re: More parallel pg_dump bogosities

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2018-08-28T19:11:46Z
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

Commits

  1. Make pg_restore's identify_locking_dependencies() more bulletproof.

  2. Code review for pg_dump's handling of ALTER INDEX ATTACH PARTITION.

  3. Fix missing dependency for pg_dump's ENABLE ROW LEVEL SECURITY items.