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

From Andres Freund
Subject Re: lcr v5 - introduction of InvalidCommandId
Date
Msg-id 20130904160708.GB32316@awork2.anarazel.de
Whole thread Raw
In response to Re: logical changeset generation v5  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: lcr v5 - introduction of InvalidCommandId
List pgsql-hackers
On 2013-09-03 11:40:57 -0400, Robert Haas wrote:
> > 0002 wal_decoding: Introduce InvalidCommandId and declare that to be the new maximum for CommandCounterIncrement
> 
> I'm still unconvinced we want this.

Ok, so the reason for the existance of this patch is that currently
there is no way to represent a "unset" CommandId. This is a problem for
the following patches because we need to log the cmin, cmax of catalog
rows and obviously there can be rows where cmax is unset.
The reason I chose to change the definition of CommandIds is that the
other ondisk types we use like TransactionIds, XLogRecPtrs and such have
an "invalid" type, CommandIds don't. Changing their definition to have 0
- analogous to the previous examples - as their invalid value is not a
problem because CommandIds from pg_upgraded clusters may never be used
for anything. Going from 2^32 to 2^32-1 possible CommandIds doesn't seem
like a problem to me. Imo the CommandIds should have been defined that
way from the start.

Makes some sense?

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Improving avg performance for numeric
Next
From: Peter Eisentraut
Date:
Subject: Re: Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)