Re: question about warm standby databases in 8.2.5

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Brett Neumeier <bneumeier(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: question about warm standby databases in 8.2.5
Date: 2007-12-11 05:32:07
Message-ID: Pine.GSO.4.64.0712110015350.2846@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, 10 Dec 2007, Brett Neumeier wrote:

> It seems that the recovery command always copies the source WAL file (with a
> name like 00000001000000020000009C) to a file path "pg_xlog/RECOVERYXLOG",
> which is fine. However, then when we abort recovery, postgresql seems to
> expect that the most recent WAL log should be in pg_xlog with its original
> filename, e.g., the 0....9C filename from above.

I think your expectation for what the recovery command script you provide
does and what the server actually requires are a little mismatched.
RECOVERYXLOG is strictly a temporary file and as you've discovered the
server may want the original back again by its original name. This has
come up before--check out this thread, from this message to the end:

http://archives.postgresql.org/pgsql-admin/2007-08/msg00425.php

It's pointed out there that the documentation is little sparse in this
area.

Not that many people run into this because there is a reference
implementation of a recovery command that correctly implements the
required behavior:

http://developer.postgresql.org/pgdocs/postgres/pgstandby.html

pg_standby ships with the upcoming 8.3, but if you grab that code you can
run it just fine against an 8.2 system. You'd be better off in the long
run (and probably the short run too) replacing whatever script you've
developed with that one, so you can just get updates to it rather than
keeping one updated in-house. Consider the time you've spend working on
your own not wasted but educational--you can never know too much about
disaster recovery of your database.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Browse pgsql-general by date

  From Date Subject
Next Message A. Kretschmer 2007-12-11 05:59:14 Re: Restore problem
Previous Message Robert Treat 2007-12-11 05:14:20 Re: partitioned table query question