Re: Materialized views WIP patch

Albe Laurenz wrote:
> Kevin Grittner wrote:
>
>> My take was more that MVs would often be refreshed by crontab, and
>> that you would want to keep subsequent steps from running and
>> generating potentially plausible but completely inaccurate results
>> if the LMV failed.
>
> If one of these subsequent steps doesn't care if refresh
> failed once, it shouldn't be forced to fail. I imagine
> that for many applications yesterday's data can be good enough.
>
> Those that care should check the timestamp.

It sounds like you and I are in agreement on this; I just didn't
state it very precisely. If a LMV on a MV which already has data
fails, the relisvalid would not prevent it from being used -- it
would be stale, but still valid data from *some* point in time. The
point is that if an MV is created WITH NO DATA or has been TRUNCATEd
and there has not been a subsequent LMV, what it contains may not
represent any state which was *ever* valid, or it may represent a
state which would only have been valid hundreds of years in the past,
had the system been computerized at that time. To me, that does not
seem like the same thing as a simple "stale" state.

I'm looking at whether there is some reasonable way to detect invalid
data as well as capture age of data. Every solution I've thought of
so far has at least one hard-to-solve race condition, but I have
hopes that I can either solve that for one of the ideas, or come up
with an idea which falls more gracefully under MVCC management.

-Kevin