Tom Lane wrote: > "Kevin Grittner" <kgri...@mail.com> writes: >> I've been struggling with two areas: >> - pg_dump sorting for MVs which depend on other MVs > > Surely that should fall out automatically given that the > dependency is properly expressed in pg_depend? > > If you mean you're trying to get it to cope with circular > dependencies between MVs, it might take some work on the pg_dump > side, but plain ordering shouldn't require new code.
The *definitions* sort properly, but what I'm trying to do is define them WITH NO DATA and load data after all the COPY statements for tables. If mva is referenced by mvb, the goal is the REFRESH mva, build its indexes before running REFRESH for mvb and building its indexes. To do things in any other order does't seem to me to leave things after restore in the same state they were in at the time of the dump. So I should have been a little more verbose describing the problem: pg_dump sorting of REFRESH and CREATE INDEX steps for MVs which depend on other MVs. Last night I found why my previous attempts had been failing -- I was trying to build the dependencies at the wrong point in the dump process, after the sorts had already been done. Now that I've spotted that fundamental flaw, I think I can get this out of the way without too much more fanfare. I kept thinking I had something wrong in the detail of my approach, while the problem was at a much higher level. Where I really need someone to hit me upside the head with a clue-stick is the code I added to the bottom of RelationBuildDesc() in relcache.c. The idea is that on first access to an unlogged MV, to detect that the heap has been replaced by the init fork, set relisvalid to false, and make the heap look normal again. I couldn't see any way to do that which wasn't a kludge, and I can't figure out how to deal with relcache properly in implementing that kludge. Either a tip about the right way to work the kludge, or a suggestion for a less kludgy alternative would be welcome. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers