Skip site navigation (1) Skip section navigation (2)

Patch to add a feature to pg_standby

From: chris(dot)johnson(at)desknetinc(dot)com
To: pgsql-patches(at)postgresql(dot)org
Subject: Patch to add a feature to pg_standby
Date: 2008-04-02 16:43:22
Message-ID: OFC93D5496.045F4BE7-ON8525741F.00572A1C-8525741F.005BE956@desknetinc.com (view raw or flat)
Thread:
Lists: pgsql-patches
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)

Please consider incorporating this feature.

Chris
_____________________________________________
Christopher K. Johnson
Director of IT
DeskNet Inc.
RHCE# 804005699817957

"A society grows great when old men plant trees whose shade they know they
shall never sit in" - Greek Proverb

Attachment: pg_standby.c.diff
Description: application/octet-stream (3.5 KB)

Responses

pgsql-patches by date

Next:From: Peter EisentrautDate: 2008-04-02 19:10:16
Subject: Changes to building dynamically loadable modules
Previous:From: Chris MarcellinoDate: 2008-04-02 15:55:18
Subject: Re: [HACKERS] POSIX shared memory support

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group