pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Michael Banck <michael.banck@credativ.de>
Cc: Jim Nasby <Jim.Nasby@bluetreble.com>
Cc: Kevin Grittner <kgrittn@gmail.com>
Cc: Jordan Gigov <coladict@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Change in "policy" on dump ordering?
Date: Wed, 26 Jul 2017 09:30:30 -0400
Message-ID: <22969.1501075830@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+TgmoYiUTPQGCjHYJ6DeiR1Qf-74XFO2Rp2WZnA88FdorZg6g@mail.gmail.com>
References: <8f64786e-824d-7c0d-33a6-3d9e1c8e9fde@2ndquadrant.com>
	<edc1dc0d-66ba-0d9e-b0e7-890f064789d7@BlueTreble.com>
	<33b25c65-94f1-6ff6-c717-61a56294a255@2ndquadrant.com>
	<a537995b-ccdb-f668-5f67-98e9b9b4a99d@BlueTreble.com>
	<75409fb1-bd96-25c2-f6b0-c24e28ed2684@2ndquadrant.com>
	<65049c27-96bf-317b-b435-931f6041f94c@BlueTreble.com>
	<67d35333-ef65-074a-b2be-52440f245e43@2ndquadrant.com>
	<753dcafc-a648-9041-e9ca-e405cd4498f4@2ndquadrant.com>
	<20170306083342.GA8374@nighthawk.caipicrew.dd-dns.de>
	<2605f6d0-8444-528e-4e38-6b13968cfeb7@2ndquadrant.com>
	<20170306140101.GQ9812@tamriel.snowman.net>
	<28572.1500912583@sss.pgh.pa.us>
	<18658.1501037135@sss.pgh.pa.us>
	<CA+TgmoYiUTPQGCjHYJ6DeiR1Qf-74XFO2Rp2WZnA88FdorZg6g@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (29+ messages)  latest in thread

Message-ID: <22969.1501075830@sss.pgh.pa.us>
Permalink:  ../22969.1501075830@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/22969.1501075830@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, sfrost@snowman.net, peter.eisentraut@2ndquadrant.com, michael.banck@credativ.de, Jim.Nasby@bluetreble.com, kgrittn@gmail.com, coladict@gmail.com
  Subject: Re: Change in "policy" on dump ordering?
  In-Reply-To: <22969.1501075830@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox