On Fri, Sep 26, 2014 at 12:32 PM, Andres Freund <and...@2ndquadrant.com> wrote: >> Huh? That's just to say that the unused bit space is, in fact, >> unused. But so what? We've always been very careful about using up >> things like infomask bits, because there are only so many bits >> available, and when they're gone they are gone. > > I don't think that's a very meaningful comparison. The problem with > infomask bits is that it's impossible to change anything once added > because of pg_upgrade'ability. That problem does not exist for > XLogRecord. We've twiddled with the WAL format pretty much in every > release. We can reconsider every release. > > I can't remember anyone but me thinking about using these two bytes. So > the comparison here really is using two free bytes vs. issuing at least > ~30 (record + origin) for every replayed transaction. Don't think that's > a unfair tradeof.
Mmph. You have a point about the WAL format being easier to change. "Reconsidering", though, would mean that some developer who probably isn't you needs those bytes for something that really is a more general need than this, so they write a patch to get them back by doing what I proposed - and then it gets rejected because it's not as good for logical replication. So I'm not sure I really buy this as an argument. For all practical purposes, if you grab them, they'll be gone. >> > I've also wondered about that. Perhaps we simply should have an >> > additional 'name' column indicating the replication solution? >> >> Yeah, maybe, but there's still the question of substructure within the >> non-replication-solution part of the name. Not sure if we can assume >> that a bipartite identifier, specifically, is right, or whether some >> solutions will end up with different numbers of components. > > Ah. I thought you only wanted to suggest a separator between the > replication solution and it's internal dat. But you actually want to > suggest an internal separator to be used in the solution's namespace? > I'm fine with that. I don't think we can suggest much beyond that - > different solutions will have fundamentally differing requirements about > which information to store. Agreed. -- 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
