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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Change in "policy" on dump ordering?
Дата
Msg-id CA+TgmoYiUTPQGCjHYJ6DeiR1Qf-74XFO2Rp2WZnA88FdorZg6g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Change in "policy" on dump ordering?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Change in "policy" on dump ordering?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Дмитрий Воронин
Дата:
Сообщение: Re: [HACKERS] pg_dump issues
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" inchild table must be marked NOT NULL