Thread: BUG #8655: pg_restore problems with materialized views

BUG #8655: pg_restore problems with materialized views

From
shaunc@factfiber.com
Date:
The following bug has been logged on the website:

Bug reference:      8655
Logged by:          Shaun Cutts
Email address:      shaunc@factfiber.com
PostgreSQL version: 9.3.1
Operating system:   mac os 10.8.5
Description:

I have a large database (100s of millions of rows) in which there are many
"chained" materialized views -- that is: some depend on others, etc...


When I back up and then restore, only the "first layer" of views are
refreshed. I can then go back and manually restore missing views with "-t"
-- though if I do too many at once the same thing happens.


I have tried to generate a small test case, but with no luck. I suspect that
pg_restore needs to issue "refresh" before it creates successive views, and
in "small" cases it gets that right -- but there is some arbitrariness in
the order that trips it up in sufficiently complex cases.


I also have indexes defined on the materialized views. I don't know if that
matters -- an extra sequencing problem for restore though.

Re: BUG #8655: pg_restore problems with materialized views

From
Kevin Grittner
Date:
"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