Oops, > But thats not what happening here, afaics the "restore log file ..." > message is only printed if the returncode is 0.
You're right. 'cp <nonexistent> <somewhere>' exits with the status code 1 (or 256?). The quoted log lines simply show that segment for tli=3 did not exist and that for tli=2 had been gotten finally. It's quite normal and irrelevant to the trouble mentioned. Sorry for the confusion. Unfortunately, the script attached didn't reproduce the situation for me. But in the log attached, > [Standby] 2013-04-22 01:27:25 EDTFATAL: XX000: could not receive data from > WAL stream: FATAL: requested WAL segment 000000030000000000000014 has > already been removed > cp: cannot stat `../arc/000000030000000000000014': No such file or directory. > [Standby] 2013-04-22 01:27:30 EDTDEBUG: 00000: unexpected pageaddr 0/6000000 > in log file 0, segment 20, offset 0 seems showing that the standby received negative ack for the request for 20th segment, and 5 seconds later, it tried to get that from archive and somehow thought that it'd gotten but the header is of 6th segment. regards, -- Kyotaro Horiguchi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
