Re: lcr v5 - introduction of InvalidCommandId
От | Robert Haas |
---|---|
Тема | Re: lcr v5 - introduction of InvalidCommandId |
Дата | |
Msg-id | CA+TgmoaE=Fqx1giPdQsPQqNQHHn77jAhhxoU-zCAR19uuAQADQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: lcr v5 - introduction of InvalidCommandId (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: lcr v5 - introduction of InvalidCommandId
|
Список | pgsql-hackers |
On Thu, Sep 5, 2013 at 12:59 PM, Andres Freund <andres@2ndquadrant.com> wrote: > On 2013-09-05 12:44:18 -0400, Robert Haas wrote: >> On Wed, Sep 4, 2013 at 12:07 PM, Andres Freund <andres@2ndquadrant.com> wrote: >> > 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. >> >> For heap tuples, we solve this problem by using flag bits. Why not >> adopt the same approach? > > We can, while it makes the amount of data stored/logged slightly larger > and it seems to lead to less idiomatic code to me, so if there's another > -1 I'll go that way. OK. Consider me more of a -0 than a -1. Like I say, I don't really want to block it; I just don't feel comfortable committing it unless a few other people say something like "I don't see a problem with that".Or maybe point me to relevant changeset extractioncode that's going to get messier. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: