Re: testing cvs HEAD - HS/SR - cannot stat

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Erik Rijkers <er(at)xs4all(dot)nl>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: testing cvs HEAD - HS/SR - cannot stat
Date: 2010-02-04 07:51:41
Message-ID: 3f0b79eb1002032351m18fd388dl1ea66c3b67ceba90@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 4, 2010 at 6:39 AM, Erik Rijkers <er(at)xs4all(dot)nl> wrote:
> However, whenever (re-)starting the slave the I get
> messages like:
>
> cp: cannot stat `/var/data1/pg_stuff/dump/replication_archive/000000010000000000000002': No such
> file or directory
>
> At this point,  /var/data1/pg_stuff/dump/replication_archive:
>
> -rw------- 1 xxxxxxxx xxxxxxxx      240 Feb  3 22:35 000000010000000000000001.00000020.backup
> -rw------- 1 xxxxxxxx xxxxxxxx 16777216 Feb  3 22:35 000000010000000000000001
> -rw------- 1 xxxxxxxx xxxxxxxx 16777216 Feb  3 22:35 000000010000000000000000
>
>
> Maybe the message is not really a bug: everything works fine otherwise.

Yeah, this is not a bug.

At first, the standby performs an archive recovery until an invalid
WAL record is found. Then it starts replication and tries to receive
the missing WAL records from the primary. So such an error message
would be logged whenever an invalid record is found and replication
is started.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message KaiGai Kohei 2010-02-04 08:30:39 Re: Largeobject Access Controls (r2460)
Previous Message Fujii Masao 2010-02-04 07:28:03 Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION