Hi Simon,<br /> I would preserve the existing trigger function as little t "-t", and maybe implement a catchup trigger
functionas big t "-T"? Set it up so that if the first attempt to find the WAL file postgres is currently requesting
succeeds,skip over the trigger check. If the first attempt fails, then do your trigger check. That way, in the OCF
script,the postmaster can be started, the trigger file set, and connection to the database looped on until it succeeds
asan indication for when the database is up and available. I think that's cleaner than comparing a filename from a 'ps'
command.Once I've completed the OCF script and done some testing, I'll forward it to you for you to review and see if
youwant to include it.<br /><br /> Thanks,<br /> Doug<br /><br /> On Thu, 2007-03-08 at 15:37 +0000, Simon Riggs wrote:
<blockquotetype="CITE"><pre>
<font color="#000000">On Thu, 2007-03-08 at 10:33 -0500, Doug Knight wrote:</font>
<font color="#000000">> Thanks, Simon. I kind of figured that's how pg_standby would work,</font>
<font color="#000000">> since its invoked by postgres once per WAL file. What I was thinking I</font>
<font color="#000000">> might do in the OCF script is to grab the pg_standby process line from</font>
<font color="#000000">> a ps, pull out the "current" WAL file path and filename, then do an</font>
<font color="#000000">> existence check for the file. If the file exists, then</font>
<font color="#000000">> pg_standby/postgres is probably processing it. If not, then we're</font>
<font color="#000000">> probably waiting on it, implying that recovery is complete. Thoughts</font>
<font color="#000000">> on this process?</font>
<font color="#000000">I suppose I might be able to have the option to catch up before it</font>
<font color="#000000">stops, on the basis that if it can find the file it was looking for</font>
<font color="#000000">without waiting then that can override the trigger.</font>
<font color="#000000">Which way would you like it to work?</font>
</pre></blockquote>
