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>
> >> 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
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
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
> >> > 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.
So, let's recommend underscores as that separator?
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: