From: | Sergi Casbas <sergi(dot)casbas(at)iris(dot)cat> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Marko Tiikkaja <marko(at)joh(dot)to>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #13444: psql can't recover a pg_dump. |
Date: | 2015-06-18 12:11:14 |
Message-ID: | CA+Q_62ao6+CTVKYz954mH_gZ+_Oo71kzX0eqO8JvY-V6m=cs+g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
HI!
I discovered (and solve) the problem.
Materialized View schema1.MV calls function public.F and function public.F
uses table public.T
Inside the function we made something like:
.....
SELECT * FROM T;
.....
Then when the pgsql is recreating the schema can not acces T because is on
schema1.
The solution: change public.F code using complete name:
SELECT * FROM public.T;
Sergi Casbas
*Scrum Master*
*Email: sergi(dot)casbas(at)iris(dot)cat <sergi(dot)casbas(at)iris(dot)cat>Phone Direct : +34 93
554 25 05 <%2B34-93-554-25-05>*
2015-06-17 0:08 GMT+02:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Marko Tiikkaja <marko(at)joh(dot)to> writes:
> > This sounds like it might be a duplicate of bug #12465:
> >
> http://www.postgresql.org/message-id/20150108212429.11502.18220@wrigleys.postgresql.org
>
> It's hard to tell on the basis of the supplied info what exactly is the
> OP's specific problem. However, although I rejected #12465 as not-a-bug,
> there definitely are issues with functions in materialized views, because
> pg_dump lacks enough information to understand what dependencies might be
> implied by the bodies of the functions. We've also seen reports of cases
> where it nominally worked, but took forever, because execution of the
> matview queries was too slow for lack of not-yet-restored indexes or for
> lack of planner statistics.
>
> A simple response would be to delay all the REFRESH MATVIEW commands to
> the end of the dump script, but (1) that doesn't fix the lack-of-ANALYZE
> problem, and (2) it plays hob with the notion of pre-data/data/post-data
> section boundaries, unless you're willing to reclassify the REFRESH
> commands as not being "data".
>
> regards, tom lane
>
--
Web: www.iris.cat; Twitter: www.
<http://t.signauxcinq.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XZsdDZcWW4WJ24g63RS0FW4XyMQH56dPj7dpZnKn02?t=http%3A%2F%2Fwww.%2F&si=5061214055432192&pi=3b9b88cc-a5b6-420c-818b-b7d44bc26dc7>
twitter.com/iris_rd
<http://t.signauxcinq.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XZsdDZcWW4WJ24g63RS0FW4XyMQH56dPj7dpZnKn02?t=http%3A%2F%2Ftwitter.com%2Firis_rd&si=5061214055432192&pi=3b9b88cc-a5b6-420c-818b-b7d44bc26dc7>
LinkedIn: www.linkedin.com/company/iris-s.l.
--
--
Parc Mediterrani de la Tecnologia, Avda. Carl Friedrich Gauss 11, 08860
Castelldefels, Barcelona (Spain)
Phone office: +34 93 554 25 00;
NexusUCD, University College Dublin, Blocks 9 & 10 Belfield Office Park Belfield,
Dublin (Ireland)
Phone office: +353 (0)1 716 5791;
Privacy Policy:
http://www.iris.cat/wp-content/uploads/2014/01/PoliticaDePrivacidad.pdf
<http://t.signauxcinq.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJN7t5XZsdDZcWW4WJ24g63RS0FW4XyMQH56dPj7dpZnKn02?t=http%3A%2F%2Fwww.iris.cat%2Fwp-content%2Fuploads%2F2014%2F01%2FPoliticaDePrivacidad.pdf&si=5061214055432192&pi=3b9b88cc-a5b6-420c-818b-b7d44bc26dc7>
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2015-06-18 14:54:51 | Re: BUG #13453: PostgreSQL 9.5dev pgbench exponential distribution bug? (when threshold is small) |
Previous Message | Christoph Berg | 2015-06-18 10:53:05 | Re: [GENERAL] pg_xlog on a hot_standby slave filling up |