On Thu, Mar 26, 2009 at 4:54 AM, Guillaume Smet <guillaume.s...@gmail.com>wrote:
> Hi Simon.
>
> On Thu, Mar 26, 2009 at 11:50 AM, Simon Riggs <si...@2ndquadrant.com>
> wrote:
> > 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.
>
> Or you can define both files in your command line to have the choice.
>
> I like the idea of removing -t and adding 2 new options so that people
> are warned about the intended behavior.
>
> Anyway, I don't have a strong opinion about how we should fix it as I
> don't use pg_standby personnally, just that we should. The two options
> you mention have their own merits.
>
>
For the record, I have been a user of pg_standby in the past, and never
realized this behavioural detail; probably because we never had a huge lag
at the slave.
>From implementation perspective, I'd vote against any new options. That'd
just make it harder for backporting to older branches. I like the idea that
contents of the trigger file determines the mode of operation.
So, we can keep the existing behaviour where an empty trigger file waits for
all WAL files to be applied, hence no surprises for existing users. With
some strong wordings in the docs, we emit a log message like
'Trigger file found; Performing patient recovery'
that makes the user read the docs and understand the difference, if he has
not already done so. And if there are some contents in the trigger file,
then the behaviour depends on that.
If we do not want to go to lengths of reading the file contents, the
behaviour can depend on the suffix of the file.
pg_standby -t /tmp/mytrigger ... -- lest assume this is the restore_command
if( exists /tmp/mytrigger ) do default patient recovery with appropriate
messages in log
if( exists /tmp/mytrigger.fast ) do stop the recovery immediately with a
message in log
if( exists /tmp/mytrigger.normal ) do the patient recovery with messages in
log
Best regards,
--
gurjeet[.sin...@enterprisedb.com
singh.gurj...@{ gmail | hotmail | indiatimes | yahoo }.com
EnterpriseDB http://www.enterprisedb.com
Mail sent from my BlackLaptop device
