Simon Riggs <simon@2ndquadrant.com> wrote on 04/30/2008 07:49:44 AM:

> On Wed, 2008-04-30 at 11:29 +0100, Heikki Linnakangas wrote:
> > chris.johnson@desknetinc.com 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 (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches