Re: lcr v5 - introduction of InvalidCommandId

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: lcr v5 - introduction of InvalidCommandId
Date: 2013-09-04 16:07:08
Message-ID: 20130904160708.GB32316@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2013-09-04 16:08:19 Re: Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)
Previous Message Peter Eisentraut 2013-09-04 16:06:35 Re: Improving avg performance for numeric