Thread: 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