Alvaro Herrera writes:
> On 2018-Aug-28, Tom Lane wrote:
>> 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
On 2018-Aug-28, Tom Lane wrote:
> ... 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
... 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.
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> And lastly, the ROW SECURITY items are ready because they are not marked
> >> with any dependency at all, none, nada. This seems bad. In principle
> >> it could mean that
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> And lastly, the ROW SECURITY items are ready because they are not marked
>> with any dependency at all, none, nada. This seems bad. In principle
>> it could mean that parallel restore would try to emit "ALTER TABLE ENABLE
>> ROW
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> So I started poking at the idea of sorting by size during parallel
> restore instead of sorting pg_dump's TOC that way. While investigating
> just where to do that, I discovered that, using the regression database
> as test case,
