Simon Riggs <[EMAIL PROTECTED]> wrote on 04/30/2008 07:49:44 AM: > On Wed, 2008-04-30 at 11:29 +0100, Heikki Linnakangas wrote: > > [EMAIL PROTECTED] wrote: > > > When using pg_standby to remain in recovery mode on a warm standby system, > > > if there is a need to perform other actions in coordination with recovery > > > actions, the -x <auxiliary command> option implemented by this patch > > > enables that coordination. I considered adding the ability to > override the > > > restoreCommand, however by keeping this separate and optional it is > > > possible to force retries of the auxiliary command until successful and > > > still utilize pg_usleep instead of looping within an external script or > > > command. And the previous behavior of pg_standby remains unchanged (other > > > than debug logging and documenting the option in usage) if the new option > > > is omitted. > > > > > > I added this feature to help with synchronization of a content repository > > > consisting of a PostgreSQL db for meta-information and a separate file > > > store for content. > > > The auxiliary command enables forcing an rsync of the file storethat is at > > > least as current as the found WAL segment file's db changes, and prevents > > > recovery of that WAL file unless the rsync can be performed successfully. > > > > > > (See attached file: pg_standby.c.diff) > > > > This could be implemented by a "pass-through" restore_command, that > > calls pg_standby, and does the custom action when pg_standby returns > > successfully. > > Yes, that's the preferred route for most cases. > > pg_standby was designed to be customisable, so if it works for Chris, > thats OK. > > After some mulling on this, I'm not sure we need to include this in > pg_standby however. If we did we'd end up having before/after commands > and retry options etc. > > -- > Simon Riggs > 2ndQuadrant http://www.2ndQuadrant.com > I did not wish to presume that the WAL file being copied or linked into the destination would cause no issues should the engine be shutdown during my custom action or retry loop, and subsequently restarted in recovery mode. Which is why I chose to insert executing the command after determining that the file was available, but before the mv/cp. I like your suggestion of before/after commands and retry options. It offers flexibility in pg_standby far beyond my specific needs.
Not having studied internals of postgres I am not sure, but it seemed to me that the other value provided by this implementation instead of a 'pass-through' restore command is the use of pg_usleep in retry loops. If pg_standby were not to provide that retry loop for the after command, then another program would need to be written to do that. Adding the feature to pg_standby seemed the more elegant implementation. But if pg_usleep accomplishes nothing more than a sleep in a script would, then implementing the loop in pg_standby provides a trivial advantage. Chris -- Sent via pgsql-patches mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches