On 08/26/2013 12:47 AM, Jim Nasby wrote: > On 8/23/13 11:23 AM, Greg Stark wrote: >> This doesn't generate a unique id. You could back up a standby and >> restore it and point it at the original master and end up with two >> standbies with the same id. Yeah, not as easy as I imagined. It will fix itself once the 2nd slave starts to follow the 1st, bt this has the disadvantage that for a connected client a running system suddenly changes its "unique id".
If we want it happen automatically we have to allow erring on "too often" or "not often enough" side for some users/usages. > > If you want to enforce something unique throughout a cluster, I think > we're stuck with having the cluster communicate IDs across an entire > cluster. AFAIK that's how both Slony and londiste 3 do it. > > I think it's also noteworthy that Slony and londiste both rely on the > user specifying node identifiers. They don't try to be magic about it. > I think there's 2 advantages there: > > - Code is simpler > - Users can choose a naming schema that makes sense for them 3rd - really only users can determine when a "system" is unique and when it is a copy of another. Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
