Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VDsCS-000815-Gi for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Aug 2013 08:31:00 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VDsCR-0006A3-Tv for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Aug 2013 08:30:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VDsCP-00066n-Al for pgsql-hackers@postgresql.org; Mon, 26 Aug 2013 08:30:57 +0000 Received: from moutng.kundenserver.de ([212.227.17.9]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VDsCK-0005Wj-Qd for pgsql-hackers@postgresql.org; Mon, 26 Aug 2013 08:30:57 +0000 Received: from [192.168.42.11] ([90.174.1.77]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0Lln96-1VnD0t1XCS-00ZMc9; Mon, 26 Aug 2013 10:30:46 +0200 Message-ID: <521B1231.3080709@2ndQuadrant.com> Date: Mon, 26 Aug 2013 10:30:41 +0200 From: Hannu Krosing Organization: 2ndQuadrant Nordic =?ISO-8859-1?Q?O=DC?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jim Nasby CC: Greg Stark , Tom Lane , Andres Freund , Alvaro Herrera , Josh Berkus , PostgreSQL-development Subject: Re: pg_system_identifier() References: <5215346B.7070800@dalibo.com> <20130822134205.GC17006@awork2.anarazel.de> <52163222.9030700@agliodbs.com> <20130822155633.GF17006@awork2.anarazel.de> <14611.1377187563@sss.pgh.pa.us> <20130822161839.GG17006@awork2.anarazel.de> <20130822162019.GC10710@eldon.alvh.no-ip.org> <20130822163059.GI17006@awork2.anarazel.de> <15653.1377189456@sss.pgh.pa.us> <52177AD5.5010809@2ndQuadrant.com> <521A8985.2040509@nasby.net> In-Reply-To: <521A8985.2040509@nasby.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:xm3VtEY1zZKzKyWUl23OoYbMkA5ld2QvLuvkO4X30Yw fTP4W0eP02Ujp5jxtDam9HCxdMrKDEO7TSGvpFF87cqYVh6Wjc vvXgHPucNyDnrn89o+JkPOhBSdMrlZ6wHGDFvD/1CZJPfst0uH t1OHH5Z31dkRaVu3ll53CCG1KNVr3n6Yo+fTibhvtDlgoBmeH3 6Fufq1Ow6R2qN75F8b6WEkWCcb2WzdfhWthbfWdJ++y/pndq+9 NtyZMtWwydk9rw3SHZCNkJ9rFEqy7i07QQIgZiidbWIb6lyB7D blQAUALfza1Ns+aF8uFR+7ZCjxJvDSlMXKm4bdETIWhITdHCGO DDTIfA/0b5cSx8+w24GI= X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org 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