Re: lcr v5 - introduction of InvalidCommandId

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: lcr v5 - introduction of InvalidCommandId
Дата
Msg-id 20130904160708.GB32316@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: logical changeset generation v5  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: lcr v5 - introduction of InvalidCommandId  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Improving avg performance for numeric
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)