Обсуждение: pitr standby on slave with skewed time

Howdy folks,

Was review a clients config/setup and ran across a pitr warm standby scenario
where the master machine is set to the current time, but the slave's time is
currently sitting back in the month of May. Outside of getting ntp setup on
the machine, I am wondering if I need to do anything special with the
postgresql setup, or if just setting the correct date on the machine is a
safe enough operation that nothing else would need to be done (like re-doing
the base backup). Any thoughts?

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

Robert Treat <xzilla@users.sourceforge.net> writes:
> Was review a clients config/setup and ran across a pitr warm standby scenario
> where the master machine is set to the current time, but the slave's time is
> currently sitting back in the month of May. Outside of getting ntp setup on
> the machine, I am wondering if I need to do anything special with the
> postgresql setup, or if just setting the correct date on the machine is a
> safe enough operation that nothing else would need to be done (like re-doing
> the base backup). Any thoughts?

AFAIR you should be all right ... PITR only looks at WAL indexes, not
file timestamps.

The slave does watch the current time to decide when to do recovery
restartpoints, so if you were setting the clock *back* by a large amount
it might be wise to stop and restart the slave postmaster.  Forward
should be no problem though.

            regards, tom lane

On Fri, 2008-07-11 at 12:15 -0400, Tom Lane wrote:
> Robert Treat <xzilla@users.sourceforge.net> writes:
> > Was review a clients config/setup and ran across a pitr warm standby scenario
> > where the master machine is set to the current time, but the slave's time is
> > currently sitting back in the month of May. Outside of getting ntp setup on
> > the machine, I am wondering if I need to do anything special with the
> > postgresql setup, or if just setting the correct date on the machine is a
> > safe enough operation that nothing else would need to be done (like re-doing
> > the base backup). Any thoughts?
>
> AFAIR you should be all right ... PITR only looks at WAL indexes, not
> file timestamps.

WAL filenames, just in case anybody listening thinks "I didn't create an
index on my WAL, should I?". This is so people that set their pg_xlog
filesystem no file modification timestamps don't screw up their
recovery.

> The slave does watch the current time to decide when to do recovery
> restartpoints, so if you were setting the clock *back* by a large amount
> it might be wise to stop and restart the slave postmaster.  Forward
> should be no problem though.

Yeh, you're good.

--
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support