Simon Riggs wrote:
On Fri, 2006-07-14 at 12:09 -0400, Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
I've now thought about how to fix that without doing that rather crude
rsync-pg_xlog-hack.
I've read through the code, and learned that wal-segmen
Martijn van Oosterhout wrote:
On Fri, Jul 14, 2006 at 05:36:58PM +0200, Florian G. Pflug wrote:
That was the idea - providing pg_rotate_wal(), which would guarantee that
the wal is rotatted at least once if called. Thinking further about this,
for a first prove of concept, I'd be enou
A.M. wrote:
On Fri, July 14, 2006 11:20 am, Florian G. Pflug wrote:
Hi
For my warm-standby-cluster I'm now saving the currently used wal using
rsync, to avoid loosing data from a few hours (or days) ago, when there is
little traffic, and thus the wal isn't rotated. For online ba
Hi
For my warm-standby-cluster I'm now saving the currently used wal using rsync,
to avoid loosing data from a few hours (or days) ago, when there is little
traffic,
and thus the wal isn't rotated. For online backups, the problem is even worse,
because
a backup might me unuseable even hours aft
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 processi
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"
301 - 306 of 306 matches
Mail list logo
