Re: [HACKERS] Change in "policy" on dump ordering? - Mailing list pgsql-hackers

From Jordan Gigov
Subject Re: [HACKERS] Change in "policy" on dump ordering?
Date
Msg-id CA+nBocCTj5NAsrhEYOvY4YDo-Yg6YU5eAmhFq3NK+-K97MmxUA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Change in "policy" on dump ordering?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Change in "policy" on dump ordering?
List pgsql-hackers
But why should a superuser need the ACL to be applied before being allowed access? If you make the permission-checking function check if the user is a superuser before looking for per-user grants, wouldn't that solve the issue?

On 26 July 2017 at 16:30, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jul 25, 2017 at 10:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Instead, I've prepared the attached draft patch, which addresses the
>> problem by teaching pg_backup_archiver.c to process TOC entries in
>> three separate passes, "main" then ACLs then matview refreshes.

> What worries me a bit is the possibility that something might depend
> on a matview having already been refreshed.  I cannot immediately
> think of a case whether such a thing happens that you won't dismiss as
> wrong-headed, but how sure are we that none such will arise?

Um, there are already precisely zero guarantees about that.  pg_dump
has always been free to order these actions in any way that satisfies
the dependencies it knows about.

It's certainly possible to break it by introducing hidden dependencies
within CHECK conditions.  But that's always been true, with or without
materialized views, and we've always dismissed complaints about it with
"sorry, we won't support that".  (I don't think the trigger case is
such a problem, because we restore data before creating any triggers.)

Meanwhile, we have problems that bite people who aren't doing anything
stranger than having a matview owned by a non-superuser.  How do you
propose to fix that without reordering pg_dump's actions?

Lastly, the proposed patch has the advantage that it acts at the restore
stage, not when a dump is being prepared.  Since it isn't affecting what
goes into dump archives, it doesn't tie our hands if we think of some
better idea later.

                        regards, tom lane

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL
Next
From: Pavel Golub
Date:
Subject: [HACKERS] AlterUserStmt anmd RoleSpec rules in grammar.y