Re: More parallel pg_dump bogosities - Mailing list pgsql-hackers

From Tom Lane
Subject Re: More parallel pg_dump bogosities
Date
Msg-id 11450.1535483506@sss.pgh.pa.us
Whole thread Raw
In response to Re: More parallel pg_dump bogosities  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: More parallel pg_dump bogosities
List 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 by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: csv format for psql
Next
From: Andrey Borodin
Date:
Subject: Re: Dimension limit in contrib/cube (dump/restore hazard?)