Re: BUG #13444: psql can't recover a pg_dump.
От | Tom Lane |
---|---|
Тема | Re: BUG #13444: psql can't recover a pg_dump. |
Дата | |
Msg-id | 1817.1434492500@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #13444: psql can't recover a pg_dump. (Marko Tiikkaja <marko@joh.to>) |
Ответы |
Re: BUG #13444: psql can't recover a pg_dump.
|
Список | pgsql-bugs |
Marko Tiikkaja <marko@joh.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
В списке pgsql-bugs по дате отправления: