Обсуждение: unexpected pageaddr

Streaming replication standby moved from 9.0.2->9.0.3 logs this up
startup:

 database system was shut down in recovery at 2011-02-02 15:28:51 EST
 entering standby mode
 redo starts at 0/65000170
 consistent recovery state reached at 0/66000000
 unexpected pageaddr 0/62000000 in log file 0, segment 102, offset 0
 database system is ready to accept read only connections
 streaming replication successfully connected to primary

Is the standby hurt?

Ray Stell <stellr@cns.vt.edu> writes:
> Streaming replication standby moved from 9.0.2->9.0.3 logs this up
> startup:

>  database system was shut down in recovery at 2011-02-02 15:28:51 EST
>  entering standby mode
>  redo starts at 0/65000170
>  consistent recovery state reached at 0/66000000
>  unexpected pageaddr 0/62000000 in log file 0, segment 102, offset 0
>  database system is ready to accept read only connections
>  streaming replication successfully connected to primary

> Is the standby hurt?

"unexpected pageaddr" is just one of the standard tests for detecting
end of WAL, so I don't think this is anything to be surprised about.
It looks to me like the standby applied all the WAL it had and then
connected to the master for more.

            regards, tom lane

On Wed, Feb 02, 2011 at 06:32:22PM -0500, Tom Lane wrote:
> Ray Stell <stellr@cns.vt.edu> writes:
> > Streaming replication standby moved from 9.0.2->9.0.3 logs this up
> > startup:
>
> >  database system was shut down in recovery at 2011-02-02 15:28:51 EST
> >  entering standby mode
> >  redo starts at 0/65000170
> >  consistent recovery state reached at 0/66000000
> >  unexpected pageaddr 0/62000000 in log file 0, segment 102, offset 0
> >  database system is ready to accept read only connections
> >  streaming replication successfully connected to primary
>
> > Is the standby hurt?
>
> "unexpected pageaddr" is just one of the standard tests for detecting
> end of WAL, so I don't think this is anything to be surprised about.
> It looks to me like the standby applied all the WAL it had and then
> connected to the master for more.
>
>             regards, tom lane

thanks, Tom.  I suppose it's the order that trips me up:

 starts at 65...
 reached a 66...
 unexpected at 62...

Maybe you could say a few words on the flow logic.
I suppose it depends on what is meant by "start."

Ray Stell <stellr@cns.vt.edu> writes:
> On Wed, Feb 02, 2011 at 06:32:22PM -0500, Tom Lane wrote:
>> "unexpected pageaddr" is just one of the standard tests for detecting
>> end of WAL, so I don't think this is anything to be surprised about.
>> It looks to me like the standby applied all the WAL it had and then
>> connected to the master for more.

> thanks, Tom.  I suppose it's the order that trips me up:

>  starts at 65...
>  reached a 66...
>  unexpected at 62...

Well, the point of the "unexpected pageaddr" message is exactly that the
WAL location it found in the next file wasn't the expected next location
in sequence (which would have to be something larger than 0/66000000).
This indicates that the next file isn't really new WAL, but a segment
file that was recycled (by renaming it to a higher file number) but not
yet overwritten with new data.

            regards, tom lane

Have you tried connecting to the standby?

If the standby is in progress, then it should refuse with a "Database
Starting message" IIRC. If this is the case, I'd say it's fine...

Until someone comes along and corrects me of course...

Cheers

-----Original Message-----
From: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Ray Stell
Sent: 02 February 2011 20:47
To: pgsql-admin@postgresql.org
Subject: [ADMIN] unexpected pageaddr

Streaming replication standby moved from 9.0.2->9.0.3 logs this up
startup:

 database system was shut down in recovery at 2011-02-02 15:28:51 EST
 entering standby mode
 redo starts at 0/65000170
 consistent recovery state reached at 0/66000000
 unexpected pageaddr 0/62000000 in log file 0, segment 102, offset 0
 database system is ready to accept read only connections
 streaming replication successfully connected to primary

Is the standby hurt?

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

___________________________________________________

This email is intended for the named recipient. The information contained
in it is confidential.  You should not copy it for any purposes, nor
disclose its contents to any other party.  If you received this email
in error, please notify the sender immediately via email, and delete it from
your computer.

Any views or opinions presented are solely those of the author and do not
necessarily represent those of the company.

PCI Compliancy: Please note, we do not send or wish to receive banking, credit
or debit card information by email or any other form of communication.

Cromwell Tools Limited, PO Box 14, 65 Chartwell Drive
Wigston, Leicester LE18 1AT. Tel 0116 2888000
Registered in England and Wales, Reg No 00986161
VAT GB 115 5713 87 900
__________________________________________________