Re: New trigger option of pg_standby - Mailing list pgsql-hackers

From Gurjeet Singh
Subject Re: New trigger option of pg_standby
Date
Msg-id 65937bea0903300604p38894624r80ddf6160e6ae987@mail.gmail.com
Whole thread Raw
In response to Re: New trigger option of pg_standby  (Guillaume Smet <guillaume.smet@gmail.com>)
List pgsql-hackers
<div class="gmail_quote">On Thu, Mar 26, 2009 at 4:54 AM, Guillaume Smet <span dir="ltr"><<a
href="mailto:guillaume.smet@gmail.com">guillaume.smet@gmail.com</a>></span>wrote:<br /><blockquote
class="gmail_quote"style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi
Simon.<br/><div class="im"><br /> On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs <<a
href="mailto:simon@2ndquadrant.com">simon@2ndquadrant.com</a>>wrote:<br /> > Earlier, we discussed having a
singletrigger file that contains an<br /> > option rather than two distinct trigger files. That design is better<br
/>> because it allows the user to choose at failover time, rather than<br /> > making a binding decision at
configtime. That solution would be the<br /> > ideal one, IMHO, because it gives user more choice - and would allow
us<br/> > to keep the -t option meaningfully. In that case the default should be<br /> > patience.<br /><br
/></div>Oryou can define both files in your command line to have the choice.<br /><br /> I like the idea of removing -t
andadding 2 new options so that people<br /> are warned about the intended behavior.<br /><br /> Anyway, I don't have a
strongopinion about how we should fix it as I<br /> don't use pg_standby personnally, just that we should. The two
options<br/> you mention have their own merits.<br /><br /></blockquote></div><br />For the record, I have been a user
ofpg_standby in the past, and never realized this behavioural detail; probably because we never had a huge lag at the
slave.<br/><br />From implementation perspective, I'd vote against any new options. That'd just make it harder for
backportingto older branches. I like the idea that contents of the trigger file determines the mode of operation.<br
/><br/>So, we can keep the existing behaviour where an empty trigger file waits for all WAL files to be applied, hence
nosurprises for existing users. With some strong wordings in the docs, we emit a log message like<br /><br /> 'Trigger
filefound; Performing patient recovery'<br /><br />that makes the user read the docs and understand the difference, if
hehas not already done so. And if there are some contents in the trigger file, then the behaviour depends on that.<br
/><br/>If we do not want to go to lengths of reading the file contents, the behaviour can depend on the suffix of the
file.<br/><br />pg_standby -t /tmp/mytrigger ...  -- lest assume this is the restore_command<br /><br />if( exists
/tmp/mytrigger) do default patient recovery with appropriate messages in log<br /> if( exists /tmp/mytrigger.fast ) do
stopthe recovery immediately with a message in log<br />if( exists /tmp/mytrigger.normal ) do the patient recovery with
messagesin log<br /><br />Best regards,<br />-- <br />gurjeet[.singh]@EnterpriseDB.com<br /> singh.gurjeet@{ gmail |
hotmail| indiatimes | yahoo }.com<br /><br />EnterpriseDB      <a
href="http://www.enterprisedb.com">http://www.enterprisedb.com</a><br/><br />Mail sent from my BlackLaptop device<br /> 

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: 8.3.5: Crash in CountActiveBackends() - lockless race?
Next
From: Sergey Burladyan
Date:
Subject: Re: gettext, plural form and translation