On 02/19/2014 11:15 PM, Neil Thombre wrote:
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.
https://github.com/postgres/postgres/blob/REL9_1_11/contrib/pg_standby/pg_standby.c#L456
There is also a comment above it about not "upsetting" the server.
https://github.com/postgres/postgres/blob/REL9_1_11/contrib/pg_standby/pg_standby.c#L454
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
CheckForStandbyTrigger() here:
https://github.com/postgres/postgres/blob/REL9_1_11/src/backend/access/transam/xlog.c#L10441
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?
At end-of-recovery, the server will fetch again the last WAL file that
was replayed. If it can no longer find it, because restore_command now
returns an error even though it succeeded for the same file few seconds
earlier, it will throw an error and refuse to start up.
That's the way it used to be until 9.2, anyway. In 9.2, the behavior was
changed, so that the server keeps all the files restored from archive,
in pg_xlog, so that it can access them again. I haven't tried, but it's
possible that the truncation is no longer necessary. Try it, with 9.1
and 9.3, and see what happens.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
