Re: how is pitr replay interruption time determined?

Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> writes:
> Is there some way to force checkpoints on a db doing wal replay?

No, it's hardwired to do it when it sees a checkpoint record in the WAL stream.

> pg_control last modified: Mon Aug 27 12:12:55 2007
> Time of latest checkpoint: Mon Jul 30 19:17:37 2007

After looking again at the code, the "last modified" time is the time
that a recovery checkpoint was last done, and the "latest checkpoint"
is the timestamp of the WAL-stream checkpoint record that triggered it.
In a situation where you're catching up on historical WAL they could be
far apart, but when a slave is just following the master there shouldn't
be a huge difference --- not more than the maximum time to fill a WAL
record and ship it over to the slave, for sure.

(BTW, I misread it before --- it looks like the "at log time" value
printed at startup *is* taken from the checkpoint record that it's
trying to roll forward from.)

Assuming that you're absorbing data from the master at a steady rate,
the only reason I can see for the timestamps to be so old is if the
"rm_safe_restartpoint" checks are always failing. I seem to remember
that we found and fixed a bug that could cause something like that,
but I can't find any trace of it in the CVS logs. Simon, do you
recall such a problem post-8.2.0?

regards, tom lane