On Mon, Jun 23, 2014 at 10:11 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> > Why? Users and other systems only ever see the external ID. Everything
>> > leaving the system is converted to the external form. The short id
>> > basically is only used in shared memory and in wal records. For both
>> > using longer strings would be problematic.
>> >
>> > In the patch I have the user can actually see them as they're stored in
>> > pg_replication_identifier, but there should never be a need for that.
>>
>> Hmm, so there's no requirement that the short IDs are consistent
>> across different clusters that are replication to each other?
>
> Nope. That seemed to be a hard requirement in the earlier discussions we
> had (~2 years ago).
Oh, great. Somehow I missed the fact that that had been addressed. I
had assumed that we still needed global identifiers in which case I
think they'd need to be 64+ bits (preferably more like 128). If they
only need to be locally significant that makes things much better.
Is there any real reason to add a pg_replication_identifier table, or
should we just let individual replication solutions manage the
identifiers within their own configuration tables? I guess one
question is: What happens if there are multiple replication solutions
in use on a single server? How do they coordinate?
>> If
>> that's the case, that might address my concern, but I'd probably want
>> to go back through the latest patch and think about it a bit more.
>
> I'll send out a new version after I'm finished with the newest atomic
> ops patch.
Sweet. I'm a little backed up right now, but will look at it when able.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
