understanding minimum recovery ending location

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
pg_control last modified: Wed 29 Dec 2010 04:54:04 PM GMT
Latest checkpoint location: 56/234325B0
Prior checkpoint location: 56/21020CA8
Latest checkpoint's REDO location: 56/220558A8
Time of latest checkpoint: Wed 29 Dec 2010 04:51:09 PM GMT
Minimum recovery ending location: 0/0
Backup start location: 0/0
Current wal_level setting: hot_standby

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
http://www.xzilla.net