Re: testing cvs HEAD - HS/SR - cannot stat

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
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> 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 get rid of this in that case?

Yeah, removed.

>>> LOG: restore_command = 'cp /home/hlinnaka/pgsql.cvshead/walarchive/%f %p'
>>> LOG: standby_mode = 'true'
>>> LOG: primary_conninfo = 'host=localhost port=5432 user=rep_user password=reppass'
>>> LOG: trigger_file = '/tmp/standby-trigger'
>> Do we really need to echo all the lines in recovery.conf? That might be
>> interesting information, but perhaps it could be condensed and worded
>> more nicely.
>
> It's OK for me to move them from LOG to DEBUG.

Done.

>>> cp: cannot stat `/home/hlinnaka/pgsql.cvshead/walarchive/000000010000000000000007': No such file or directory
>> This is the noise line Josh started this thread with.
>
> Agreed. But the messages other than ENOENT that restore_command emits
> might be useful.
>
>>> LOG: automatic recovery in progress
>> Ok, so what?
>
> Seems unnecessary.

I replaced this with a more informative message that says either:

"entering standby mode", or
"starting point-in-time recovery to XID %u", or
"starting archive recovery"

>>> LOG: initializing recovery connections
>> Seems like unnecessary noise, doesn't mean anything to a DBA.
>
> Agreed.

Demoted to DEBUG1.

>>> LOG: redo starts at 0/700140C
>> I guess this could be useful debug information sometimes.
>
> Agreed.

I left this as it was.

>>> LOG: consistent recovery state reached at 0/700142C
>> It's nice to know that it has reached consistency, but was there any way
>> to know before this line that it hadn't been reached yet? Perhaps the
>> "redo starts" line should mention that consistency hasn't been reached yet.
>
> But redo might restart from the consistent database if the standby
> server was shut down after it reached the consistent status.

Yeah, it would be nice to say whether the database is already consistent
or not, but I've left this alone for now.

>> Now, should we print a line when we connect to the master successfully?
>> Seems like useful information.
>
> Agreed.
>
>> Then there's the LOG lines whenever a file is restored successfully from
>> archive; are the necessary anymore, now that you can connect to the
>> standby and use pg_last_xlog_replay_location() to poll its status?
>
> How about moving those messages from LOG to DEBUG?

Didn't touch these yet.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com