Re: CLUSTER FREEZE

On Sun, Dec 8, 2013 at 10:51 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On Tue, 2013-11-19 at 18:24 +0100, Andres Freund wrote:
>> On 2013-11-19 12:23:30 -0500, Robert Haas wrote:
>> > On Mon, Nov 18, 2013 at 11:45 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> > >> Yes, we probably should make a decision, unless Robert's idea can be
>> > >> implemented. We have to balance the ease of debugging MVCC failures
>> > >> with the interface we give to the user community.
>> > >
>> > > Imo that patch really doesn't need too much further work.
>> >
>> > Would you care to submit a version you're happy with?
>>
>> I'll give it a spin sometime this week.
>
> I'm setting the CLUSTER FREEZE patch as returned with feedback, until
> this other patch has been considered.

The other patch in question is now committed. Here's a patch for
this, which does somewhat more extensive surgery than previously
proposed (actually, I wrote it from scratch, before looking at the
prior submission). It's basically the same idea, though. Note that
both versions of the patch affect not only CLUSTER, but also VACUUM
FULL.

I suspect we ought to extend this to rewriting variants of ALTER TABLE
as well, but a little thought is needed there. ATRewriteTables()
appears to just call heap_insert() for each updated row, which if I'm
not mistaken is an MVCC violation - offhand, it seems like a
transaction with an older MVCC snapshot could access the table for
this first time after the rewriter commits, and fail to see rows which
would have appeared to be there before the rewrite. (I haven't
actually tested this, so watch me be wrong.) If we're OK with an MVCC
violation here, we could just pass HEAP_INSERT_FROZEN and have a
slightly different flavor of violation; if not, this needs some kind
of more extensive surgery quite apart from what we do about freezing.

Review of the attached appreciated...

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