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: http://www.postgresql.org/mailpref/pgsql-hackers
