Re: BUG #8655: pg_restore problems with materialized views

"shaunc@factfiber.com" <shaunc@factfiber.com> wrote:=0A=0A> I have a large =
database (100s of millions of rows) in which there=0A> are many "chained" m=
aterialized views -- that is: some depend on=0A> others, etc...=0A>=0A> Whe=
n I back up and then restore, only the "first layer" of views=0A> are refre=
shed. I can then go back and manually restore missing=0A> views with "-t"=
=0A> -- though if I do too many at once the same thing happens.=0A>=0A> I h=
ave tried to generate a small test case, but with no luck.=0A=0AYeah, it sh=
ould work, and I have run a lot of test cases without=0Aseeing this.=A0 The=
 one case that is a little weird is when you=0Apopulate a materialized view=
 "b" which references materialized view=0A"a", REFRESH MATERIALIZED VIEW "a=
" WITH NO DATA, and then dump.=0A=0A> I suspect that pg_restore needs to is=
sue "refresh" before it=0A> creates successive views, and in "small" cases =
it gets that right=0A> -- but there is some arbitrariness in the order that=
 trips it up=0A> in sufficiently complex cases.=0A=0AThat does sound likely=
, but without a failing case, it is going to=0Abe hard to diagnose.=0A=0A> =
I also have indexes defined on the materialized views. I don't=0A> know if =
that matters -- an extra sequencing problem for restore=0A> though.=0A=0ATh=
ose are all supposed to be handled, but if there is an=0Aunidentified bug, =
who knows what matters?=0A=0AHave you tried restoring a schema-only dump an=
d populating it with=0Aminimal data, and seeing whether you can replicate i=
t that way?=0A=0A--=0AKevin Grittner=0AEDB: http://www.enterprisedb.com=0AT=
he Enterprise PostgreSQL Company