On Mon, Jun 23, 2014 at 10:11 AM, Andres Freund <and...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to