Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id A1A60632550 for ; Thu, 26 Mar 2009 07:50:14 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 83883-09 for ; Thu, 26 Mar 2009 07:50:04 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail129153.authsmtp.net (outmail129153.authsmtp.net [62.13.129.153]) by mail.postgresql.org (Postfix) with ESMTP id 6F74C632365 for ; Thu, 26 Mar 2009 07:50:03 -0300 (ADT) Received: from mail-c193.authsmtp.com (mail-c193.authsmtp.com [62.13.128.118]) by punt7.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id n2QAnxj8090673; Thu, 26 Mar 2009 10:49:59 GMT Received: from [192.168.0.4] (85-211-223-92.dyn.gotadsl.co.uk [85.211.223.92]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id n2QAnwlS075941; Thu, 26 Mar 2009 10:49:59 GMT Subject: Re: New trigger option of pg_standby From: Simon Riggs To: Guillaume Smet Cc: Fujii Masao , Kevin Grittner , pgsql-hackers In-Reply-To: <1d4e0c10903260032v767da1fdg6cf7cea86c64cc45@mail.gmail.com> References: <3f0b79eb0903242329j12865d55s348f5c873a956e71@mail.gmail.com> <1d4e0c10903242350i505a9f6bsa7ba347dc02f90b6@mail.gmail.com> <3f0b79eb0903250144k453b3927mffa8b08678ed057b@mail.gmail.com> <1d4e0c10903250155w34bd79dcvfab2ad5c95e56011@mail.gmail.com> <49C9F255.EE98.0025.0@wicourts.gov> <1d4e0c10903250848x4e067c86ue611c0c50f25e49d@mail.gmail.com> <3f0b79eb0903251851v5936d6b4x49997ac8f04b98b9@mail.gmail.com> <1d4e0c10903260032v767da1fdg6cf7cea86c64cc45@mail.gmail.com> Content-Type: text/plain Date: Thu, 26 Mar 2009 10:50:33 +0000 Message-Id: <1238064633.16568.420.camel@ebony.2ndQuadrant> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Server-Quench: da177207-19f3-11de-8a51-002264978518 X-AuthRoute: OCdxZQATClZOTQEd DAteCiNZVAwpPBRK HVkIKg5MJUcNSQVJ NksachtFagNbYFhD HGQLW11EUV17XWp/ bgMfZQBDYEtPQQdo U1ZAQE1QEQdtHhxP WBx/I0c1K2ZGf3t5 YUcsXHlbXwouJEd6 RUxUEnAHbDFjdWEe BBVFf1JRcR5Kfh1H bFR2U3sIYG1JBC9q VzwTFhsSEA9kHWxz Tx5FMUgTTkkGBHY7 XwwDGjNnGkNNXyoE NAAvLFIWDS41 X-Authentic-SMTP: 61633235383639.pelican.dmpriest.net.uk:1378/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200903/1040 X-Sequence-Number: 135718 On Thu, 2009-03-26 at 08:32 +0100, Guillaume Smet wrote: > On Thu, Mar 26, 2009 at 2:51 AM, Fujii Masao wrote: > > What does "the default" mean? You mean that new trigger should use > > the existing trigger option character (-t)? > > Yes, that's my point. > > I understand it seems weird to switch the options but I'm pretty sure > a lot of persons currently using -t would be surprised by the current > behaviour. Moreover playing all the remaining WALs before starting up > should be the most natural option when people are looking in the help. If the standby has fallen behind then waiting for it to catch up might take hours to failover if it waits for all files. If you haven't been monitoring it correctly, you have no clue. That is also a surprising thing, so let's not jump from one surprising thing into the arms of another. If we go with this, I would suggest we make *neither* the default by removing -t, and adopting two new options: something like -f == fast failover, -p == patient failover. This then forces people to read and understand the difference between the two behaviours so they can make an informed choice of how they would like to act at this critical point in time. It is justifiable because there is no single thing called a trigger file any longer and the concept will lead to pain. Earlier, we discussed having a single trigger file that contains an option rather than two distinct trigger files. That design is better because it allows the user to choose at failover time, rather than making a binding decision at config time. That solution would be the ideal one, IMHO, because it gives user more choice - and would allow us to keep the -t option meaningfully. In that case the default should be patience. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support