Re: Replication identifiers, take 3

On Fri, Sep 26, 2014 at 10:21 AM, Andres Freund <andres(at)2ndquadrant(dot)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 get that, but what I'm asking is why those mappings can't be managed
>> on a per-replication-solution basis. I think that's just because
>> there's a limited namespace and so coordination is needed between
>> multiple replication solutions that might possibly be running on the
>> same system. But I want to confirm if that's actually what you're
>> thinking.
>
> Yes, that and that such a mapping needs to be done across all database
> are the primary reasons. As it's currently impossible to create further
> shared relations you'd have to invent something living in the data
> directory on filesystem level... Brr.
>
> I think it'd also be much worse for debugging if there'd be no way to
> map such a internal identifier back to the replication solution in some
> form.

OK.

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company