I asked a question over on StackOverflow, and Craig Ringer told me to report it here.
http://stackoverflow.com/questions/24413161/how-can-i-prevent-materialized-views-from-refreshing-during-pg-restore I have created a dump of the database using pg_dump in "custom" format (-Fc). This format allows for pg_restore to be invoked with the "jobs" option (-j8). The jobs options starts 8 processes, and restores the vast majority of relations in my database within 10 minutes. I'm left with 4 processes. One of them is the refresh of a materialized view, and the other 3 are indexes to be applied to 3 tables that the materialized view uses as data sources. The indexes are "waiting" according to pg_stat_activity, presumably because the REFRESH of the materialized view is still accessing the source tables. When the indexes are in place, the refresh of the view only takes a couple of minutes. Because the indexes are not in place during the REFRESH, I cut the REFRESH process off at 17 hours, which made pg_restore fail. How can I Force the order of items so the indexes get created first Turn off the refresh of the materialized view and do it manually later Manipulate the dump file in custom format to say "WITH NO DATA" Intercept the REFRESH MATERIALIZED VIEW statement and throw it in the trash Or any other solution that gets the job done? I have a dump file that I'm willing to send to somebody that seems to reproduce the problem pretty consistently. Thank you, /Kirk -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
