On 2014-09-26 14:57:12 -0400, Robert Haas wrote: > 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.
Sure, it'll possibly not be trivial to move them elsewhere. On the other hand, the padding bytes have been unused for 8+ years without somebody laying "claim" on them but "me". I don't think it's a good idea to leave them there unused when nobody even has proposed another use for a long while. That'll just end up with them continuing to be unused. And there's actually four more consecutive bytes on 64bit systems that are unused. Should there really be a dire need after that, we can simply bump the record size. WAL volume wise it'd not be too bad to make the record a tiny bit bigger - the header is only a relatively small fraction of the entire content. > >> > 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. So, let's recommend underscores as that separator? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
