I was trying to understand (and then perhaps mimic) how pg_standby does a
My current understanding is that when a secondary db is in standby mode, it
will exhaust all the archive log to be replayed from the primary and then
start streaming. It is at this point that xlog.c checks for the existence
of a trigger file to promote the secondary. This was been a cause of some
irritation for some of our customers who do not really care about catching
up all the way. I want to achieve the exact semantics of pg_standby's fast
I manipulated the restore command to return 'failure' when the word "fast"
is present in the trigger file (see below), hoping that when I want a
secondary database to come out fast, I can just echo the word "fast" into
the trigger file thereby simulating pg_standby's fast failover behavior.
However, that did not work. Techically, I did not truncate the trigger file
like how pg_standby.
<New restore_command> = ! fgrep -qsi fast <trigger_file> && <Old
And that is where I have a question. I noticed that in pg_standby.c when we
detect the word "fast" in the trigger file we truncate the file.
There is also a comment above it about not "upsetting" the server.
What is the purpose of truncating the file? To do a smart failover once you
come out of standby? But, when I look at xlog.c, when we come out of
standby due to a failure returned by restore_command, we call
Now, CheckForStandbyTrigger() unlinks the trigger file. I noticed through
the debugger that the unlinking happens before xlog.c makes a call to the
next restore_command. So, what is the reason for truncating the "fast"
word from the trigger file if the file is going to be deleted soon after it
is discovered? How will we "upset" the server if we don't?
Assuming this question is answered and I get a better understanding, I have
a follow up question. If truncation is indeed necessary, can I simulate
the truncation by manipulating restore_command and achieve the same effect
as a fast failover in pg_standby?
Thanks in advance for the help.