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 store that 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 -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
