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

From Robert Haas
Subject Re: [HACKERS] Change in "policy" on dump ordering?
Date
Msg-id CA+TgmoYiUTPQGCjHYJ6DeiR1Qf-74XFO2Rp2WZnA88FdorZg6g@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
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.
> It's survived light testing but could doubtless use further review.

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?

I mean, a case that would actually break is if you had a CHECK
constraint or a functional index that contained a function which
referenced a materialized view for some validation or transformation
purpose.  Then it wouldn't be formally immutable, of course.  But
maybe we can imagine that some other case not involving lying could
exist, or come to exist.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Дмитрий Воронин
Date:
Subject: Re: [HACKERS] pg_dump issues
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" inchild table must be marked NOT NULL