On Thu, Sep 5, 2013 at 12:59 PM, Andres Freund <and...@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 <and...@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 extraction code that's going to get messier. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
