Simon, * Simon Riggs (si...@2ndquadrant.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
signature.asc
Description: Digital signature