Skip site navigation (1) Skip section navigation (2)

how is pitr replay interruption time determined?

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: pgsql-admin(at)postgresql(dot)org
Subject: how is pitr replay interruption time determined?
Date: 2007-08-27 21:42:57
Message-ID: 200708271742.57392.xzilla@users.sourceforge.net (view raw or flat)
Thread:
Lists: pgsql-admin
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

Responses

pgsql-admin by date

Next:From: Daniel MuñozDate: 2007-08-27 21:47:09
Subject: Re: Problems connecting to postgres using JDBC Driver.
Previous:From: Scott MarloweDate: 2007-08-27 21:40:25
Subject: Re: Copy cmd error

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group