From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marko Tiikkaja <marko(at)joh(dot)to> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Sergi Casbas <sergi(dot)casbas(at)iris(dot)cat>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #13444: psql can't recover a pg_dump. |
Date: | 2015-06-16 22:08:20 |
Message-ID: | 1817.1434492500@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Lacey Powers | 2015-06-16 22:12:36 | Re: [GENERAL] pg_xlog on a hot_standby slave filling up |
Previous Message | Tom Lane | 2015-06-16 22:01:14 | Re: BUG #13440: unaccent does not remove all diacritics |