understanding minimum recovery ending location - Mailing list pgsql-hackers

Howdy, 

I am hoping someone can help me better understand what the "minimum recovery ending location" of pg_controldata represents with regards to 9.0 hot standbys. When I look at any of our 8.4 (or lower) installs this number is almost always somewhere in the past of the xlog timeline (presuming the server has been up for any length of time), which makes sense because we've done enough replay that we're covered for consistent slave recovery purposes. However, on the hot standby machines the number seems to normally be at some point in the future. Below is the relevant bits of pg_controldata output from a hot standby I was looking at earlier today: 

Database cluster state:               in archive recovery

pg_control last modified:             Wed 29 Dec 2010 04:54:34 PM GMT

Latest checkpoint location:           56/21020CA8

Prior checkpoint location:            56/1E36D780

Latest checkpoint's REDO location:    56/1F599068

Time of latest checkpoint:            Wed 29 Dec 2010 04:46:09 PM GMT

Minimum recovery ending location:     56/24B88500

Backup start location:                0/0

Current wal_level setting:            hot_standby

As you can see, the minimum recovery ending location is clearly ahead of the most recent checkpoint activity. Now, it's not always like this, but most of the time it is, and since minimum recovery ending location seems to be regularly be updating going forward, it tends to make me think that either I misunderstand what this means, or it means something different in this context. Partially because I can query on the hot standby machine already, so I know I have a recoverable slave, but even more so in the context of pg_controldata on the master:

Database cluster state:               in production

As you can see, the masters checkpoint information is actually ahead of the slaves (as expected), but even in this scenario, the slave is saying that the minimum recovery ending location is actually in the future compared to the latest checkpoint and redo locations of the master. This seems like a bug to me (how can it possibly be required that the minimum recovery ending location would be at a point in the xlog timeline that may never exist?) , but I am guessing this field  is actually reporting something different in this context, so I am hoping someone can help clarify it for me? 

Robert Treat