Re: Replication identifiers, take 3 - Mailing list pgsql-hackers

On 2014-09-26 11:02:16 -0400, Robert Haas wrote:
> On Fri, Sep 26, 2014 at 10:55 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > On 2014-09-26 10:40:37 -0400, Robert Haas wrote:
> >> On Fri, Sep 26, 2014 at 10:21 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> >> > As explained above this isn't happening on the level of individual AMs.
> >>
> >> Well, that's even worse.  You want to grab 100% of the available
> >> generic bitspace applicable to all record types for purposes specific
> >> to logical decoding (and it's still not really enough bits).
> >
> > I don't think that's a fair characterization. Right now it's available
> > to precisely nobody. You can't put any data in there in *any* way. It
> > just has been sitting around unused for at least 8 years.
> 
> 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.

> >> One question I have is what the structure of the names should be.  It
> >> seems some coordination could be needed here.  I mean, suppose BDR
> >> uses bdr:$NODENAME and Slony uses
> >> $SLONY_CLUSTER_NAME:$SLONY_INSTANCE_NAME and EDB's xDB replication
> >> server uses xdb__$NODE_NAME.  That seems like it would be sad.  Maybe
> >> we should decide that names ought to be of the form
> >> <replication-solution>.<further-period-separated-components> or
> >> something like that.
> >
> > 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.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services