Re: Replication identifiers, take 3

On 2014-09-26 14:57:12 -0400, Robert Haas wrote:
> On Fri, Sep 26, 2014 at 12:32 PM, Andres Freund <andres@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