On Fri, Jan 13, 2012 at 12:58 AM, Satoshi Nagayasu <snaga@uptime.jp> wrote:
> Anyway, how about this one?
>
> If we have 47 in archive, and 48 in pg_xlog,
>
> (1) LOG: restored log file "000000080000000000000047" from archive
> (2) LOG: replaying log file "000000080000000000000047"
> (3) LOG: could not restore file "000000080000000000000048" from archive
> (4) LOG: replaying log file "000000080000000000000048"
>
> In this case, "(4) replying" after "(3) could not restore from archive"
> would means that it has started replaying a WAL from pg_xlog.
Looks confusing. In this way, you always need to look at more than one
messages to understand the meaning of one message. Which seems
not good design. What if lots of log files exist in pg_xlog and you got
the following message? To figure out where the log file 98 comes from,
you need to find (3) from lots of log messages.
LOG: replaying log file "000000080000000000000098"
What about the following simpler way?
(1) LOG: restored log file "000000080000000000000047" from archive (2) LOG: replaying log file
"000000080000000000000047"from archive (4) LOG: replaying log file "000000080000000000000048" from pg_xlog
In file-base log-shipping with standby_mode=on case, restoring from archive
is repeated periodically, which would flood the log file with the messages
like (3). So I don't like emitting the message like (3) with LOG level.
> I just got another option in my mind.
>
> Telling both two numbers of WAL files, from archive and
> pg_xlog directory, those have been applied during archive recovery
> would make sense?
>
> How about this one?
>
> LOG: XXX file(s) from archive, YYY file(s) from pg_xlog successfully
> applied.
What's the use case of this message?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
