On 30.12.2010 00:19, Robert Treat wrote:
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.

Minimum recovery ending location means: how far does the (standby) server need to replay WAL before it's safe to start it up. It is continuously updated as the recovery progresses, as data pages are flushed to disk. The reason is that if you kill the server during recovery, you have to recover up to the same point again, or the database wouldn't be consistent. Specifically, the WAL records for any data page changes that were already flushed to disk from the buffer cache before killing recovery must be re-replayed.

So in practice the minimum recovery ending location follows somewhat behind the last replayed WAL record.

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

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

Reply via email to