I would preserve the existing trigger function as little t "-t", and
maybe implement a catchup trigger function as 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 as an 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
you want to include it.
On Thu, 2007-03-08 at 15:37 +0000, Simon Riggs wrote:
> On Thu, 2007-03-08 at 10:33 -0500, Doug Knight wrote:
> > Thanks, Simon. I kind of figured that's how pg_standby would work,
> > since its invoked by postgres once per WAL file. What I was thinking I
> > might do in the OCF script is to grab the pg_standby process line from
> > a ps, pull out the "current" WAL file path and filename, then do an
> > existence check for the file. If the file exists, then
> > pg_standby/postgres is probably processing it. If not, then we're
> > probably waiting on it, implying that recovery is complete. Thoughts
> > on this process?
> I suppose I might be able to have the option to catch up before it
> stops, on the basis that if it can find the file it was looking for
> without waiting then that can override the trigger.
> Which way would you like it to work?