Today I was running some tests on one of our warm standbys. The way this test
works is I took a zfs snapshot of the filesystem, induce failover, of the
pitr host, then log in and play around with the data. Once we're done with
this, I rolled back the zfs snapshot, restart the standby instance, and let
it start doing wal_replay again. All of this seems to work fine, but when I
start the replay instance again I get the following line in my logfile:
LOG: database system was interrupted while in recovery at log time 2007-07-30
19:17:37 EDT
I am curious how this date is determined by postgres/pitr? The standby had
processed wal_logs right through today before having taken the zfs snapshot,
so I would think it would have been interrupted at a log time of sometime
today. Also the initial replay setup occured sometime was long before 07-30,
so that doesn't correspond to that date either, so I'm wondering what it is
that determines the point in time that replay thinks it is interuppted at.
FWIW, this does have practical implecations, like how many wal files to keep
around, in my case I had all the files going back to that date, so I only had
to wait for replay to catch up.... 5 hours later :-). But it would be good
to be able to predetermine that kind of thing.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
