Re: [HACKERS] Change in "policy" on dump ordering?

Michael Banck writes: > Am Donnerstag, den 27.07.2017, 15:52 -0400 schrieb Tom Lane: >> So I'm thinking we should consider the multi-pass patch I posted as >> a short-term, backpatchable workaround, which we could hope to >> replace with dependency logic later. > +1,

Re: [HACKERS] Change in "policy" on dump ordering?

Am Donnerstag, den 27.07.2017, 15:52 -0400 schrieb Tom Lane: > So I'm thinking we should consider the multi-pass patch I posted as > a short-term, backpatchable workaround, which we could hope to > replace with dependency logic later. +1, it would be really nice if this could be fixed in the

Re: [HACKERS] Change in "policy" on dump ordering?

Robert Haas writes: > On Wed, Jul 26, 2017 at 2:41 PM, Tom Lane wrote: >> The bigger issue is whether there's some failure case this would cause >> that I'm missing altogether. Thoughts? > I think dependencies are fundamentally the right model for

Re: [HACKERS] Change in "policy" on dump ordering?

On Wed, Jul 26, 2017 at 2:41 PM, Tom Lane wrote: > The bigger issue is whether there's some failure case this would cause > that I'm missing altogether. Thoughts? I think dependencies are fundamentally the right model for this sort of problem. I can't imagine what could go

Re: [HACKERS] Change in "policy" on dump ordering?

I thought of a quite different way that we might attack this problem, but I'm not sure if it's worth pursuing or not. The idea is basically that we should get rid of the existing kluge for pushing ACLs to the end altogether, and instead rely on dependency sorting to make things work. This'd

Re: [HACKERS] Change in "policy" on dump ordering?

On Wed, Jul 26, 2017 at 9:30 AM, Tom Lane wrote: > 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? Obviously changing the

Re: [HACKERS] Change in "policy" on dump ordering?

Jordan Gigov writes: > 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? The superuser's

Re: [HACKERS] Change in "policy" on dump ordering?

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 wrote: >

Re: [HACKERS] Change in "policy" on dump ordering?

Robert Haas writes: > On Tue, Jul 25, 2017 at 10:45 PM, Tom Lane 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

Re: [HACKERS] Change in "policy" on dump ordering?

On Tue, Jul 25, 2017 at 10:45 PM, Tom Lane 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. > It's survived light

Re: [HACKERS] Change in "policy" on dump ordering?

I wrote: > The main problem with Kevin's fix, after thinking about it more, is that > it shoves matview refresh commands into the same final processing phase > where ACLs are done, which means that in a parallel restore they will not > be done in parallel. That seems like a pretty serious

Re: [HACKERS] Change in "policy" on dump ordering?

Stephen Frost writes: > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: >> On 3/6/17 03:33, Michael Banck wrote: >>> Would this be a candidate for backpatching, or is the behaviour change >>> in pg_dump trumping the issues it solves? >> Unless someone literally

Re: [HACKERS] Change in "policy" on dump ordering?

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 3/6/17 03:33, Michael Banck wrote: > > Would this be a candidate for backpatching, or is the behaviour change > > in pg_dump trumping the issues it solves? > > Unless someone literally has a materialized view on pg_policy, it >

Re: [HACKERS] Change in "policy" on dump ordering?

On 3/4/17 11:49 AM, Peter Eisentraut wrote: I wonder whether we should emphasize this change by assigning DO_REFRESH_MATVIEW a higher number, like 100? Since there wasn't any interest in that idea, I have committed Jim's patch as is. Thanks. Something else that seems somewhat useful would be

Re: [HACKERS] Change in "policy" on dump ordering?

On 3/6/17 03:33, Michael Banck wrote: > Would this be a candidate for backpatching, or is the behaviour change > in pg_dump trumping the issues it solves? Unless someone literally has a materialized view on pg_policy, it wouldn't make a difference, so I'm not very keen on bothering to backpatch

Re: [HACKERS] Change in "policy" on dump ordering?

Hi, On Sat, Mar 04, 2017 at 02:49:36PM -0500, Peter Eisentraut wrote: > On 3/1/17 08:36, Peter Eisentraut wrote: > > On 2/22/17 18:24, Jim Nasby wrote: > >>> Yes, by that logic matview refresh should always be last. > >> > >> Patches for head attached. > >> > >> RLS was the first item added after

Re: [HACKERS] Change in "policy" on dump ordering?

On 3/1/17 08:36, Peter Eisentraut wrote: > On 2/22/17 18:24, Jim Nasby wrote: >>> Yes, by that logic matview refresh should always be last. >> >> Patches for head attached. >> >> RLS was the first item added after DO_REFRESH_MATVIEW, which was added >> in 9.5. So if we want to treat this as a

Re: [HACKERS] Change in "policy" on dump ordering?

On 2/22/17 18:24, Jim Nasby wrote: > On 2/22/17 12:29 PM, Peter Eisentraut wrote: >> On 2/22/17 10:14, Jim Nasby wrote: >>> CREATE MATERIALIZED VIEW tmv AS SELECT * FROM pg_subscription; >>> SELECT 0 >>> >>> IOW, you can create matviews that depend on any other >>> table/view/matview, but right

Re: [HACKERS] Change in "policy" on dump ordering?

Hi, I've found the (AIUI) previous discussion about this, it's Bug #13907: https://www.postgresql.org/message-id/flat/20160202161407.2778.24659%40wrigleys.postgresql.org#20160202161407.2778.24...@wrigleys.postgresql.org On Wed, Feb 22, 2017 at 05:24:49PM -0600, Jim Nasby wrote: > On 2/22/17

Re: [HACKERS] Change in "policy" on dump ordering?

On 2/22/17 5:38 PM, Michael Banck wrote: diff --git a/src/bin/pg_dump/pg_dump_sort.c b/src/bin/pg_dump/pg_dump_sort.c index ea643397ba..708a47f3cb 100644 --- a/src/bin/pg_dump/pg_dump_sort.c +++ b/src/bin/pg_dump/pg_dump_sort.c @@ -26,6 +26,9 @@ static const char *modulename =

Re: [HACKERS] Change in "policy" on dump ordering?

Hi, On Wed, Feb 22, 2017 at 05:24:49PM -0600, Jim Nasby wrote: > On 2/22/17 12:29 PM, Peter Eisentraut wrote: > >On 2/22/17 10:14, Jim Nasby wrote: > >>CREATE MATERIALIZED VIEW tmv AS SELECT * FROM pg_subscription; > >>SELECT 0 > >> > >>IOW, you can create matviews that depend on any other >

Re: [HACKERS] Change in "policy" on dump ordering?

Jim, * Jim Nasby (jim.na...@bluetreble.com) wrote: > On 2/22/17 12:29 PM, Peter Eisentraut wrote: > >On 2/22/17 10:14, Jim Nasby wrote: > >>CREATE MATERIALIZED VIEW tmv AS SELECT * FROM pg_subscription; > >>SELECT 0 > >> > >>IOW, you can create matviews that depend on any other >

Re: [HACKERS] Change in "policy" on dump ordering?

On 2/22/17 12:29 PM, Peter Eisentraut wrote: On 2/22/17 10:14, Jim Nasby wrote: CREATE MATERIALIZED VIEW tmv AS SELECT * FROM pg_subscription; SELECT 0 IOW, you can create matviews that depend on any other table/view/matview, but right now if the matview includes certain items it will

Re: [HACKERS] Change in "policy" on dump ordering?

On 2/22/17 10:14, Jim Nasby wrote: > CREATE MATERIALIZED VIEW tmv AS SELECT * FROM pg_subscription; > SELECT 0 > > IOW, you can create matviews that depend on any other > table/view/matview, but right now if the matview includes certain items > it will mysteriously end up empty post-restore.

Re: [HACKERS] Change in "policy" on dump ordering?

On 2/22/17 8:00 AM, Peter Eisentraut wrote: Actually, I think matviews really need to be the absolute last thing. What if you had a matview that referenced publications or subscriptions? I'm guessing that would be broken right now. I'm not sure what you have in mind here. Publications and

Re: [HACKERS] Change in "policy" on dump ordering?

On 2/22/17 00:55, Jim Nasby wrote: > Originally, no, but reviewing the list again I'm kindof wondering about > DO_DEFAULT_ACL, especially since the acl code in pg_dump looks at > defaults as part of what removes the need to explicitly dump > permissions. I'm also wondering if DO_POLICY could

Re: [HACKERS] Change in "policy" on dump ordering?

On 2/21/17 4:25 PM, Peter Eisentraut wrote: On 2/21/17 14:58, Jim Nasby wrote: AFAICT in older versions only object types that absolutely had to wait for DO_POST_DATA_BOUNDARY would do so. More recently though, objects are being added after that (presumably because it's easier than renumbering

Re: [HACKERS] Change in "policy" on dump ordering?

On 2/21/17 14:58, Jim Nasby wrote: > AFAICT in older versions only object types that absolutely had to wait > for DO_POST_DATA_BOUNDARY would do so. More recently though, objects are > being added after that (presumably because it's easier than renumbering > everything in dbObjectTypePriority).

[HACKERS] Change in "policy" on dump ordering?

AFAICT in older versions only object types that absolutely had to wait for DO_POST_DATA_BOUNDARY would do so. More recently though, objects are being added after that (presumably because it's easier than renumbering everything in dbObjectTypePriority). Is this change a good or bad idea?