From: | Satoshi Nagayasu <snaga(at)uptime(dot)jp> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: log messages for archive recovery progress |
Date: | 2012-01-12 15:58:57 |
Message-ID: | 4F0F0341.3050007@uptime.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2012/01/13 0:13, Robert Haas wrote:
> On Thu, Jan 12, 2012 at 10:04 AM, Simon Riggs<simon(at)2ndquadrant(dot)com> wrote:
>> On Thu, Jan 12, 2012 at 2:13 PM, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
>>> On Wed, Jan 11, 2012 at 9:01 AM, Simon Riggs<simon(at)2ndquadrant(dot)com> wrote:
>>>> On Wed, Jan 11, 2012 at 1:54 PM, Satoshi Nagayasu<snaga(at)uptime(dot)jp> wrote:
>>>>
>>>>> 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".
>>>>
>>>> Agreed. I can change "restored" to "using", so we have two message types
>>>>
>>>> LOG: restored log file "000000080000000000000047" from archive
>>>> LOG: using pre-existing log file "000000080000000000000047" from pg_xlog
>>>
>>> using seems pretty fuzzy to me. replaying?
>>
>> That was my first thought, but the message relates to which file has
>> been selected, and how. Once it has been selected it will be replayed.
>> The idea is to have the two messages look similar.
>>
>> The original message was "restored log file..." and says nothing about
>> replaying.
>>
>> We could change the old message (ugh! backwards compatibility alert)
>>
>> LOG: replaying log file "000000080000000000000047" after restore from archive
>> LOG: replaying log file "000000080000000000000047" already in pg_xlog
>>
>> which doesn't sound much stronger to me... not sure.
>
> Hmm, I don't know. But that phrasing does at least have the advantage
> of being clearly parallel, which I like.
It seems difficult to keep backward compatibility. :)
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.
And if we have 47 in archive, and do not have 48 in pg_xlog,
(5) LOG: restored log file "000000080000000000000047" from archive
(6) LOG: replaying log file "000000080000000000000047"
(7) LOG: could not restore file "000000080000000000000048" from archive
(8) LOG: could not replay file "000000080000000000000048"
In this case, "(8) could not replay file" after "(7) could not restore
from archive" would means that "48" is not found both archive and
pg_xlog, so that the latest WAL would gone.
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.
Thanks,
--
Satoshi Nagayasu <snaga(at)uptime(dot)jp>
Uptime Technologies, LLC. http://www.uptime.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-01-12 16:06:10 | Re: Remembering bug #6123 |
Previous Message | Heikki Linnakangas | 2012-01-12 15:51:56 | Re: pgbench post-connection command |