Re: Remaining beta blockers - Mailing list pgsql-hackers

On Mon, Apr 29, 2013 at 3:34 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
> The hysteria and FUD about using the currently-supported technique
> for unlogged tables to implement unlogged matviews are very
> discouraging.  And the notion that we would release a matview
> feature which allowed false results (in the form of treating a
> never-populated matview as a legal empty matview) is truly scary to
> me.

I think that labeling other people's concerns as hysteria and FUD is
not something which will advance the debate.  I might be
misunderstanding the nature of Tom's concern, but I believe the
concern is not so much that whatever bugs exist now can't be fixed,
but that the use of this mechanism might leave us vulnerable to a
steady stream of future bugs or make it hard to do things which, in
the future, we may want to do.

To take one not-particularly-hypothetical example of that, I was
recently discussing with someone, probably Noah, the idea of adding a
command to pre-extend a relation to a certain number of blocks (and
prevent vacuum from truncating those extra blocks away again).  If
you're counting on the number of blocks in the relation to mean
something other than the number of blocks in the relation, there's a
potential conflict there.   Now maybe the fact that you've defined 0
to mean non-scannable and 1+ to mean scannable means there's no real
problem with that particular idea... but suppose you'd defined it the
other way around.  I don't think it's purely unreasonable to think
that this could conflict with future developments in other areas.

The basic problem here is that the way unlogged tables work is kind of
a crock.  I didn't fully realize that at the time I implemented it,
but it's boxed us in a little in terms of trying to extend that
feature; for example, we still don't have a way to convert logged
relations to unlogged relations, or visca versa, and we're not going
to grow a way without some kind of reworking of that mechanism.  This
is another aspect of that problem.  To solve these problems cleanly,
we need either a relation metapage, or some more state in pg_class.
Short of that, this isn't a scalable solution.  Even if you think it's
workable to coax one more bit of state out of the file length, what
will you do when you need a second bit (or say another 32 bits)?

> If we can't tell the difference between those two things, I
> don't think we should be releasing the feature.

So, speaking of hysteria...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company