Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id D75C31337B84 for ; Fri, 31 Dec 2010 04:15:56 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 86303-06 for ; Fri, 31 Dec 2010 08:15:49 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from cronos.madness.at (madness.at [217.196.146.217]) by mail.postgresql.org (Postfix) with ESMTP id 96C9A1337B50 for ; Fri, 31 Dec 2010 04:15:49 -0400 (AST) Received: from gatekeeper.kaltenbrunner.cc ([83.215.243.9] helo=[192.168.8.22]) by cronos.madness.at with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PYa9F-0007Za-DL; Fri, 31 Dec 2010 09:15:44 +0100 Message-ID: <4D1D912D.7070106@kaltenbrunner.cc> Date: Fri, 31 Dec 2010 09:15:41 +0100 From: Stefan Kaltenbrunner User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101030 Iceowl/1.0b1 Icedove/3.0.10 MIME-Version: 1.0 To: Simon Riggs CC: Robert Treat , pgsql-hackers@postgresql.org Subject: Re: Sync Rep Design References: <1293729972.1892.23804.camel@ebony> <4D1CC47E.7050207@kaltenbrunner.cc> <1293735853.1892.24886.camel@ebony> <1293741390.1892.25918.camel@ebony> <1293742878.1892.26205.camel@ebony> <4D1CF4E2.5000208@kaltenbrunner.cc> <1293744431.1892.26514.camel@ebony> In-Reply-To: <1293744431.1892.26514.camel@ebony> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201012/2535 X-Sequence-Number: 177797 On 12/30/2010 10:27 PM, Simon Riggs wrote: > On Thu, 2010-12-30 at 22:08 +0100, Stefan Kaltenbrunner wrote: >> On 12/30/2010 10:01 PM, Simon Riggs wrote: >>> On Thu, 2010-12-30 at 15:51 -0500, Robert Treat wrote: >>> >>>> Still, one thing that has me concerned is that in the case of two >>>> slaves, you don't know which one is the more up-to-date one if you >>>> need to failover. It'd be nice if you could just guarantee they both >>>> are... >>> >>> Regrettably, nobody can know that, without checking. >> >> how exactly would you check? - this seems like something that needs to >> be done from the SQL and the CLI level and also very well documented >> (which I cannot see in your proposal). > > This is a proposal for sync rep, not multi-node failover. I'm definitely > not going to widen the scope of this project. > > Functions already exist to check the thing you're asking. well your proposal includes a lot of stuff on how to avoid dataloss and getting High Availability - so I think it is a requirement for us to tell the DBA what the procedures are for both setting it up (which is what is in the docs - but only 50% of the thing) and what to do in the case of a desaster (which is the other part of the problem). Or said otherwise - sync rep is not very useful if there is no easy and reliable way to get that information, if that stuff is already available even better but I'm not aware of what is there and what not, so I expect others to have the same problem. Stefan