Re: More parallel pg_dump bogosities

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

In response to


Browse pgsql-hackers by date

  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