"Kevin Grittner" <kgri...@mail.com> writes:
> Tom Lane wrote:
>> Surely that should fall out automatically given that the
>> dependency is properly expressed in pg_depend?
> 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.
Ah. Can't you treat this using the same pg_dump infrastructure as
for the data for an ordinary table? The dependencies made for the
TableDataInfo object might be a bit different, but after that it
seems like the sort logic ought to be happy.
> 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.
Hmm. I agree that relcache.c has absolutely no business doing that,
but not sure what else to do instead. Seems like it might be better
done at first touch of the MV in the parser, rewriter, or planner ---
but the fact that I can't immediately decide which of those is right
makes me feel that it's still too squishy.
I'm also wondering about locking issues there. Obviously you don't
want more than one backend trying to rebuild the MV.
Do we really need unlogged MVs in the first iteration? Seems like
that's adding a whole bunch of new issues, when you have quite enough
already without that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
