2012/01/11 19:56, Simon Riggs wrote:
2012/1/11 Euler Taveira de Oliveira<eu...@timbira.com>:
On 08-01-2012 11:59, Satoshi Nagayasu / Uptime Technologies, LLC. wrote:
[2011-12-08 15:14:36 JST] 16758: LOG: restored log file
"000000080000000000000046" from archive
[2011-12-08 15:14:36 JST] 16758: LOG: recoverying 000000080000000000000046
[2011-12-08 15:14:36 JST] 16758: LOG: restored log file
"000000080000000000000047" from archive
[2011-12-08 15:14:36 JST] 16758: LOG: recoverying 000000080000000000000047
cp: cannot stat `/backups/archlog/000000080000000000000048': No such file or
directory
[2011-12-08 15:14:37 JST] 16758: LOG: could not restore file
"000000080000000000000048" from archive
[2011-12-08 15:14:37 JST] 16758: LOG: attempting to look into pg_xlog
[2011-12-08 15:14:37 JST] 16758: LOG: recoverying 000000080000000000000048
What about just 'restored log file "000000080000000000000048" from pg_xlog'
instead of the last two messages? If you can't read from pg_xlog emit 'could
not restore file "000000080000000000000048" from pg_xlog'.
Yes, simple is better.
We already have a message if the file is not present, we just need one
if we switch to using pg_xlog.
Please look at this.
Thanks for a patch. I agree that simple is better.
However, I'm a bit afraid that it will confuse DBA if we use
"restored" under the pg_xlog replay context, because we have
already used "restored" that means a WAL file as successfully
"copied" (not "replayed") from archive directory into pg_xlog
directory under the archive recovery context.
So, to determine the status of copying WAL files from
archive directory, I think we can use "restored", or
"could not restore" on failure.
And to determine the status of replaying WAL files
in pg_xlog directory (even if a WAL is copied from archive),
we have to use "recover" or "replay".
I'll try to revise my proposed log messages again.
Thanks,
--
Satoshi Nagayasu <sn...@uptime.jp>
Uptime Technologies, LLC. http://www.uptime.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
