Re: Materialized views WIP patch

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Materialized views WIP patch
Дата
Msg-id CA+TgmobM04k=OK1rUuEkK4i26_JSsiksmnEx5R4BnhN42=Xoow@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Materialized views WIP patch  (Kevin Grittner <kgrittn@ymail.com>)
Ответы Re: Materialized views WIP patch  (Bruce Momjian <bruce@momjian.us>)
Re: Materialized views WIP patch  (Kevin Grittner <kgrittn@ymail.com>)
Список pgsql-hackers
On Fri, Feb 15, 2013 at 8:01 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
> There is one odd aspect to pg_dump, but I think the way it is
> behaving is the best way to handle it, although I invite other
> opinions.  If you load from pg_dump output, it will try to
> populated materialized views which were populated on dump, and
> leave the ones which were not scannable because the contents had
> not been generated in an empty and unscannable state on restore.
> That much seems pretty obvious.  Where it gets  a little tricky is
> if mva is generated with data, and mvb is generated based on mva.
> Then mva is truncated.  Then you dump.  mvb was populated at the
> time of the dump, but its contents can't be regenerated on restore
> because mva is not scannable.  As the patch currently stands, you
> get an error on the attempt to REFRESH mvb.  I think that's a good
> thing, but I'm open to arguments to the contrary.

Hmm, anything that means a dump-and-restore can fail seems like a bad
thing to me.  There's nothing outrageous about that scenario.  It's
arguable what state dump-and-restore should leave the new database in,
but I don't see why it shouldn't work.  I predict we'll end up with
unhappy users if we leave it like this.

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: sql_drop Event Trigger
Следующее
От: Satoshi Nagayasu
Дата:
Сообщение: Re: [RFC] pgstattuple/pgstatindex enhancement