Re: New trigger option of pg_standby

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[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com

EnterpriseDB      http://www.enterprisedb.com

Mail sent from my BlackLaptop device