Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id A3C346325D8 for ; Fri, 27 Mar 2009 09:50:13 -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 56902-09 for ; Fri, 27 Mar 2009 09:50:03 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by mail.postgresql.org (Postfix) with SMTP id 8809463245D for ; Fri, 27 Mar 2009 09:50:02 -0300 (ADT) Received: from source ([209.85.219.177]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSczLeMnslP9/fstIIBD3jK5AXbTo3HxD@postini.com; Fri, 27 Mar 2009 05:50:10 PDT Received: by ewy25 with SMTP id 25so1313130ewy.18 for ; Fri, 27 Mar 2009 05:50:00 -0700 (PDT) Received: by 10.216.28.85 with SMTP id f63mr775990wea.142.1238158200203; Fri, 27 Mar 2009 05:50:00 -0700 (PDT) Received: from ?80.223.212.7? (dsl-hkibrasgw2-fed4df00-7.dhcp.inet.fi [80.223.212.7]) by mx.google.com with ESMTPS id 28sm1817745eyg.35.2009.03.27.05.49.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Mar 2009 05:49:59 -0700 (PDT) Message-ID: <49CCCB76.4080305@enterprisedb.com> Date: Fri, 27 Mar 2009 14:49:58 +0200 From: Heikki Linnakangas Organization: EnterpriseDB User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Fujii Masao CC: Guillaume Smet , Simon Riggs , Kevin Grittner , pgsql-hackers Subject: Re: New trigger option of pg_standby 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> <1238064633.16568.420.camel@ebony.2ndQuadrant> <1d4e0c10903260454p10107c23j7ff9a3de8be09dde@mail.gmail.com> <3f0b79eb0903261938l15a6a8b8v5a7f8dec2c795cef@mail.gmail.com> In-Reply-To: <3f0b79eb0903261938l15a6a8b8v5a7f8dec2c795cef@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200903/1135 X-Sequence-Number: 135813 Fujii Masao wrote: > On Thu, Mar 26, 2009 at 8:54 PM, Guillaume Smet > wrote: >> On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs wrote: >> I like the idea of removing -t and adding 2 new options so that people >> are warned about the intended behavior. > > OK, I'll change the patch as Simon suggested; removing -t and adding > two new options: -f = fast failover (existing behavior), -p patient failover. > Also I'll default the patient failover, so it's performed when the signal > (SIGINT or SIGUSR1) is received. Uh oh, that's going to be quite tricky with signals. Remember that pg_standby is called for each file. A trigger file persists until it's deleted, but a signal will only be received by the pg_standby instance that happens to be running at the time. Makes me wonder if the trigger pg_standby with signals is reliable to begin with. What if the backend is just processing a file when the signal is fired, and there's no pg_standby process running at the moment to receive it? Seems like the signaler needs to loop until it has successfully delivered the signal to a pg_standby process, which seems pretty ugly. Given all the recent trouble with signals, and the fact that it's undocumented, perhaps we should just rip out the signaling support from pg_standby. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com