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

Magnus Hagander wrote:
> 2010/2/4 Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>:
>> Josh Berkus wrote:
>>> Can we improve the error message? Right now it's alarming people. Such as:
>>>
>>> cannot stat
>>> `/var/data1/pg_stuff/dump/replication_archive/000000010000000000000002':
>>> End of Log
>> Not really, it's coming from 'cp'. Not sure if we could capture the
>> stderr and somehow decorate the message to make it less alarming.
>>
>> This isn't really a new problem, PITR has always done that, but I agree
>> it's always been a bit clumsy to have those messages in the log.
>
> Can we follow it up with a well-phrased message that we switched to
> streaming mode right after it, so people realize it's not a problem?

Yeah, that would be a good idea. We should give the messages we emit
some holistic thinking. There's quite a few new messages printed thanks
to both Hot Standby and Streaming replication, and it seems we still
need a few more. Which ones are really required, and which ones are just
noise?

Here's what I see in a test standby server:

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

> LOG: starting archive recovery
> 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.

> cp: cannot stat `/home/hlinnaka/pgsql.cvshead/walarchive/000000010000000000000007': No such file or directory

This is the noise line Josh started this thread with.

> LOG: automatic recovery in progress

Ok, so what?

> LOG: initializing recovery connections

Seems like unnecessary noise, doesn't mean anything to a DBA.

> LOG: redo starts at 0/700140C

I guess this could be useful debug information sometimes.

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

> LOG: database system is ready to accept read only connections

This is an important piece of information with Hot Standby.

Now, should we print a line when we connect to the master successfully?
Seems like useful information.

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?

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