pg_standby: Question about truncation of trigger file in fast failover - Mailing list pgsql-hackers

From Neil Thombre
Subject pg_standby: Question about truncation of trigger file in fast failover
Date
Msg-id CACqBBXFruYK494TfGsLkCFZoOJRwRdwZ9L2k+yi+3=eia=FzSg@mail.gmail.com
Whole thread Raw
Responses Re: pg_standby: Question about truncation of trigger file in fast failover  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
<div dir="ltr"><p>I was trying to understand  (and then perhaps mimic) how pg_standby does a fast failover. <br /><p>My
currentunderstanding is that when a secondary db is in standby mode, it will exhaust all the archive log to be replayed
fromthe primary and then start streaming. It is at this point that xlog.c checks for the existence of a trigger file to
promotethe secondary. This was been a cause of some irritation for some of our customers who do not really care  about
catchingup all the way. I want to achieve the exact semantics of pg_standby's fast failover option.<p><p>I manipulated
therestore command to return 'failure' when the word "fast" is present in the trigger file (see below), hoping that
whenI want a secondary database to come out fast, I can just echo the word "fast" into the trigger file thereby
simulatingpg_standby's fast failover behavior. However, that did not work. Techically, I did not truncate the trigger
filelike how pg_standby. <br /><p><span style="font-family:courier new,monospace"><New restore_command> = ! fgrep
-qsifast <trigger_file> && <Old restore_command></span><p><br />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.  <p><a
href="https://github.com/postgres/postgres/blob/REL9_1_11/contrib/pg_standby/pg_standby.c#L456"
target="_blank">https://github.com/postgres/postgres/blob/REL9_1_11/contrib/pg_standby/pg_standby.c#L456</a><p>Thereis
alsoa comment above it about not "upsetting" the server.<p><a
href="https://github.com/postgres/postgres/blob/REL9_1_11/contrib/pg_standby/pg_standby.c#L454"
target="_blank">https://github.com/postgres/postgres/blob/REL9_1_11/contrib/pg_standby/pg_standby.c#L454</a><p>Whatis
thepurpose of truncating the file? To do a smart failover once you come out of standby? But, when I look at xlog.c,
whenwe come out of standby due to a failure returned by restore_command, we call CheckForStandbyTrigger() here: <p><a
href="https://github.com/postgres/postgres/blob/REL9_1_11/src/backend/access/transam/xlog.c#L10441"
target="_blank">https://github.com/postgres/postgres/blob/REL9_1_11/src/backend/access/transam/xlog.c#L10441</a><p>Now,
CheckForStandbyTrigger()unlinks the trigger file. I noticed through the debugger that the unlinking happens before
xlog.cmakes a call to the next restore_command.  So, what is the reason for truncating the "fast" word from the trigger
fileif the file is going to be deleted soon after it is discovered? How will we "upset" the server if we don't?<br
/><p><br/><p>Assuming this question is answered and I get a better understanding, I have a follow up question. If
 truncationis indeed necessary, can I simulate the truncation by manipulating restore_command and achieve the same
effectas a fast failover in pg_standby?<p><br /><p><br /><p>Thanks in advance for the help.<p>Neil<br /></div> 

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fwd: patch: make_timestamp function
Next
From: Emre Hasegeli
Date:
Subject: Re: GiST support for inet datatypes