Ühel kenal päeval, T, 2006-07-11 kell 08:38, kirjutas Andrew Rawnsley:
> Just having a standby mode that survived shutdown/startup would be a nice
> start...
I think that Simon Riggs did some work on this at the code sprint
yesterday.
> I also do the blocking-restore-command technique, which alth
On Mon, 2006-07-10 at 19:34 +0200, Florian G. Pflug wrote:
> This methods seems to work, but it is neither particularly fool-proof nor
> administrator friendly. It's not possible e.g. to reboot the slave without
> postgres
> abortint the recovery, and therefor processing all wals generated since
Just having a standby mode that survived shutdown/startup would be a nice
start...
I also do the blocking-restore-command technique, which although workable,
has a bit of a house-of-cards feel to it sometimes.
On 7/10/06 5:40 PM, "Florian G. Pflug" <[EMAIL PROTECTED]> wrote:
> Merlin Moncure
Merlin Moncure wrote:
On 7/10/06, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
This methods seems to work, but it is neither particularly fool-proof nor
administrator friendly. It's not possible e.g. to reboot the slave
without postgres
abortint the recovery, and therefor processing all wals gen
On 7/10/06, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
This methods seems to work, but it is neither particularly fool-proof nor
administrator friendly. It's not possible e.g. to reboot the slave without
postgres
abortint the recovery, and therefor processing all wals generated since the last
b
Hi
I've now setup a warm-standby machine by using wal archiving. The
restore_command on the
warm-standby machine loops until the wal requested by postgres appears, instead
of
returning 1. Additionally, restore_command check for two special flag-files
"abort"
and "take_online". If "take_online"
