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

Re: [HACKERS] Point in Time Recovery

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>,Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-admin(at)postgresql(dot)org
Subject: Re: [HACKERS] Point in Time Recovery
Date: 2004-07-22 03:29:08
Message-ID: 2534.1090466948@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-hackerspgsql-patches
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I think we should push the partially complete WAL file to the archive
> location before shutdown. ...
> When you are running and finally fill up the WAL file it would then
> overwrite the one in the archive but I think that is OK.

I don't think this can fly at all.  Here are some off-the-top-of-the-head
objections:

1. We don't have the luxury of spending indefinite amounts of time to
do a database shutdown.  Commonly we are under a twenty-second sentence
of death from init.  I don't want to spend the 20 seconds waiting to see
if the archiver will manage to push 16MB onto a slow tape drive.  Also,
if the archiver does fail to push the data in time, it'll likely leave a
broken (partial) xlog file in the archive, which would be really bad
news if the user then relies on that.

2. What if the archiver process entirely fails to push the file?  (Maybe
there's not enough disk space, for instance.)  In normal operation we'll
just retry every so often.  We definitely can't do that during shutdown.

3. You're blithely assuming that the archival process can easily provide
overwrite semantics for multiple pushes of the same xlog filename.  Stop
thinking about "cp to some directory" and start thinking "dump to tape"
or "burn onto CD" or something like that.  We'll be raising the ante
considerably if we require the archive_command to deal with this.

I think the last one is really the most significant issue.  We have to
keep the archiver API as simple as possible.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2004-07-22 03:36:05
Subject: Re: [HACKERS] Point in Time Recovery
Previous:From: Mark KirkwoodDate: 2004-07-22 03:12:21
Subject: Re: [HACKERS] Point in Time Recovery

pgsql-admin by date

Next:From: Bruce MomjianDate: 2004-07-22 03:36:05
Subject: Re: [HACKERS] Point in Time Recovery
Previous:From: Mark KirkwoodDate: 2004-07-22 03:12:21
Subject: Re: [HACKERS] Point in Time Recovery

pgsql-patches by date

Next:From: Bruce MomjianDate: 2004-07-22 03:36:05
Subject: Re: [HACKERS] Point in Time Recovery
Previous:From: Bruce MomjianDate: 2004-07-22 03:20:48
Subject: Re: logfile subprocess and Fancy File Functions

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