Re: lcr v5 - introduction of InvalidCommandId - Mailing list pgsql-hackers

From Andres Freund
Subject Re: lcr v5 - introduction of InvalidCommandId
Date
Msg-id 20130905192311.GD490889@alap2.anarazel.de
Whole thread Raw
In response to Re: lcr v5 - introduction of InvalidCommandId  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: lcr v5 - introduction of InvalidCommandId
List pgsql-hackers
On 2013-09-05 21:02:44 +0200, Andres Freund wrote:
> On 2013-09-05 14:37:01 -0400, Tom Lane wrote:
> > Andres Freund <andres@2ndquadrant.com> writes:
> > > On 2013-09-05 14:21:33 -0400, Tom Lane wrote:
> > >> Ideally I'd have made InvalidCommandId = 0 and FirstCommandId = 1,
> > >> but I suppose we can't have that without an on-disk compatibility break.
> >
> > > The patch actually does change it exactly that way.
> >
> > Oh.  I hadn't looked at the patch, but I had (mis)read what Robert said
> > to think that you were proposing introducing InvalidCommandId = 0xFFFFFFFF
> > while leaving FirstCommandId alone.  That would make more sense to me as
> > (1) it doesn't change the interpretation of anything that's (likely to be)
> > on disk; (2) it allows the check for overflow in CommandCounterIncrement
> > to not involve recovering from an *actual* overflow.  With the horsing
> > around we've been seeing from the gcc boys lately
>
> Ok, I can do it that way. LCR obviously shouldn't care.

It doesn't care to the point that the patch already does exactly what
you propose. It's just my memory that remembered things differently.

So, a very slightly updated patch attached.

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: Eliminating pg_catalog.pg_rewrite.ev_attr
Next
From: Alvaro Herrera
Date:
Subject: Re: Re: [HACKERS] Is it necessary to rewrite table while increasing the scale of datatype numeric?