Ok, I committed a patch to reduce the chatter a bit:
Fujii Masao wrote:
> On Fri, Feb 5, 2010 at 3:58 AM, Heikki Linnakangas
> wrote:
>>> LOG: starting archive recovery
>
> This is reported even if restore_command is not given and the WAL files are
> never restored from the archive. We should g
On Fri, Feb 5, 2010 at 3:58 AM, Heikki Linnakangas
wrote:
>> LOG: database system was interrupted while in recovery at log time
>> 2010-02-04 20:45:40 EET
>> HINT: If this has occurred more than once some data might be corrupted and
>> you might need to choose an earlier recovery target.
>
> C
Magnus Hagander wrote:
> 2010/2/4 Heikki Linnakangas :
>> Josh Berkus wrote:
>>> Can we improve the error message? Right now it's alarming people. Such as:
>>>
>>> cannot stat
>>> `/var/data1/pg_stuff/dump/replication_archive/00010002':
>>> End of Log
>> Not really, it's coming fr
On Thu, February 4, 2010 19:29, Heikki Linnakangas wrote:
> Josh Berkus wrote:
>> Can we improve the error message? Right now it's alarming people. Such as:
>>
>> cannot stat
>> `/var/data1/pg_stuff/dump/replication_archive/00010002':
>> End of Log
>
> Not really, it's coming from
2010/2/4 Heikki Linnakangas :
> Josh Berkus wrote:
>> Can we improve the error message? Right now it's alarming people. Such as:
>>
>> cannot stat
>> `/var/data1/pg_stuff/dump/replication_archive/00010002':
>> End of Log
>
> Not really, it's coming from 'cp'. Not sure if we could
Josh Berkus wrote:
> Can we improve the error message? Right now it's alarming people. Such as:
>
> cannot stat
> `/var/data1/pg_stuff/dump/replication_archive/00010002':
> End of Log
Not really, it's coming from 'cp'. Not sure if we could capture the
stderr and somehow decorate
> 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
On Thu, Feb 4, 2010 at 6:39 AM, Erik Rijkers wrote:
> However, whenever (re-)starting the slave the I get
> messages like:
>
> cp: cannot stat
> `/var/data1/pg_stuff/dump/replication_archive/00010002': No
> such
> file or directory
>
> At this point, /var/data1/pg_stuff/dump/rep
Hello,
Testing 9.0devel HS/SR: I used cvs HEAD (today) with
the new_smart_shutdown_20100201.patch of Fujii Masao.
Replication works well. The slave can be stopped and restarted.
However, whenever (re-)starting the slave the I get
messages like:
cp: cannot stat
`/var/data1/pg_stuff/dump/replic
