Re: New trigger option of pg_standby

Поиск
Список
Период
Сортировка
От Gurjeet Singh
Тема Re: New trigger option of pg_standby
Дата
Msg-id 65937bea0903300604p38894624r80ddf6160e6ae987@mail.gmail.com
обсуждение исходный текст
Ответ на Re: New trigger option of pg_standby  (Guillaume Smet <guillaume.smet@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: 8.3.5: Crash in CountActiveBackends() - lockless race?
Следующее
От: Sergey Burladyan
Дата:
Сообщение: Re: gettext, plural form and translation