Noah Misch <noah@leadboat.com> writes:
> On Wed, Apr 03, 2013 at 05:49:18PM -0400, Tom Lane wrote:
>> No. This is an absolute disaster. It's taking something we have always
>> considered to be an irrelevant implementation detail and making it into
>> user-visible DDL state, despite the fact that it doesn't begin to satisfy
>> basic transactional behaviors. We *need* to get rid of that aspect of
>> things. If you must have scannability state in version 0, okay, but
>> it has to be a catalog property not this.
> In large part, this ended up outside the catalogs due to key limitations of
> the startup process.
Yeah, I realize that there's no other (easy) way to make unlogged
matviews reset to an invalid state on crash, but that doesn't make this
design choice less of a disaster. It boxes us into something that's
entirely unable to support transitions between scannable and unscannable
states by any means short of a complete rewrite of the matview contents;
which seems fundamentally incompatible with any sort of incremental
update scenario. And I remain of the opinion that it's going to box us
into not being able to fix the problems because of pg_upgrade
on-disk-compatibility issues. We will be far better off to drop
unlogged matviews until we can come up with a better design. If that's
so far off that no one can see it happening, well, that's tough.
Leaving the door open for incremental maintenance is more important.
> A slight variation on the committed approach would be to add a "_scannable"
> relation fork.
Not very transaction-safe, I think (consider crash midway through a
transaction that adds or removes the fork), and in any case orders of
magnitude more expensive than looking at a pg_class field. This really
needs to be catalog state, not filesystem state.
regards, tom lane