Re: question on warm standby - Mailing list pgsql-admin

From Tom Lane
Subject Re: question on warm standby
Date
Msg-id 16779.1226631948@sss.pgh.pa.us
Whole thread Raw
In response to question on warm standby  ("Mark Steben" <msteben@autorevenue.com>)
Responses Re: question on warm standby  ("Mark Steben" <msteben@autorevenue.com>)
List pgsql-admin
"Mark Steben" <msteben@autorevenue.com> writes:
> I am running postgres 8.3.4 on master(mymachine) and slave(hummer).  I am
> attempting to implement warm standby.
>   1.  On mymachine I have the following archive_command:
>       Scp %p postgres@hummer:/var/backups/archlog/%f
>           (scp has been set up with ssh keys so that password
>                Is not required for postgres user)
>     This works fine.  Copies wal logs to the /var/backups/archlog directory.

Okay ...

>   2. Before I attempt pg_standby or some other wait script on hummer I have
>       Used a simple cp command in my recovery.conf file to manually restore
>        My first set of updates:

>      restore_command = 'cp /var/backups/archlog/%f  %p'

This looks fine too, perfectly standard.

>        From the doc I am assuming that %f should be the file name(s) of the
>         Wal log in /var/backups/archlog/ to be copied into the
>          /*/*/*/*/pg_xlog directory referenced by %p
>         But %f seems to be referencing current wal log names in
>          /*/*/*/*/pg_xlog.  I am getting messages like:

> cp: cannot stat `/var/backups/archlog/0000000600000003000000D2':
>       No such file or directory

Are you sure that's an error?  As per the docs, the restore_command will
sometimes be asked for files that aren't there.  I'd expect one or two
such failures in a restore session.

>       0000000600000003000000D2 is an actual wal log in hummer's
>        /*/*/*/*/pg_xlog directory.

Yeah, but is it in hummer's /var/backups/archlog ?

            regards, tom lane

pgsql-admin by date:

Previous
From: "Mark Steben"
Date:
Subject: question on warm standby
Next
From: Julius Tuskenis
Date:
Subject: Re: function executes sql 100 times longer it should