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: