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

On Fri, Feb 5, 2010 at 3:58 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> LOG:  database system was interrupted while in recovery at log time 2010-02-04 20:45:40 EET
>> HINT:  If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target.
>
> Can we avoid printing this? It's a bit alarming to talk about corrupted
> data.

I think this is useful information as a hint of data corruption. But it's
odd for this to be reported even when restarting the standby server that
has been previously shut down normally (i.e., in fact shutdown mode).

How about adding new system status like DB_SHUTDOWNED_IN_RECOVERY, setting
the status to it when the shutdown is performed during recovery, and
reporting the suitable message when starting up the server from it?

>> 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?

>> 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.

>> 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.

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

Agreed.

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

Agreed.

>> 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.

>> LOG:  database system is ready to accept read only connections
>
> This is an important piece of information with Hot Standby.

Agreed.

> 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?

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center