Re: Commits 8de72b and 5457a1 (COPY FREEZE)

Simon,

* Simon Riggs (simon(at)2ndQuadrant(dot)com) wrote:
> Visibility of pre-hinted data is an issue and because of that we
> previously agreed that it would be allowed only when explicitly
> requested by the user, which has been implemented as the FREEZE option
> on COPY. This then makes it identical to TRUNCATE, where a separate
> command differentiates MVCC-compliant row removal (DELETE) from
> non-MVCC row removal (TRUNCATE).

To be honest, I really don't buy off on this. Yes, TRUNCATE (a
top-level, individually permissioned command) can violate MVCC and make
things which might have been visible to a given transaction no longer
visible to that transaction. I find that very different from making
rows which should *not* be visible suddenly appear.

> So the committed feature does address the visibility issue.

Not hardly. It lets a user completely violate the basic rules of the
overall database. The *correct* solution to this problem is to actually
*fix* it, by setting it up such that tables created after a particular
transaction starts aren't visible and similar. Not by punting to the
user with very little control over it (or so I'm guessing). Will we
accept a patch to do an INSERT or UPDATE FREEZE...? I realize this
might be a bit of a stretch, but why not allow February 31st to be
accepted as a date also, should the user request it? This is quite a
slippery slope, in my view.

> Jeff has
> been speaking about an extension to that behaviour, which would be to
> allow HEAP_XMIN_COMMITTED to be set in some cases also. The committed
> feature specifically does not do that.

It's not clear to me why you *wouldn't* just go ahead and set everything
you can at the same time...? It hardly seems like it could be worse
than what is apparently going to happen with this command...

Thanks,

Stephen