X-Original-To: pgsql-admin-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 98E55D1B285 for ; Thu, 22 Jul 2004 00:29:16 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 91644-03 for ; Thu, 22 Jul 2004 03:29:19 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id 0428BD1B262 for ; Thu, 22 Jul 2004 00:29:12 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.11/8.12.11) with ESMTP id i6M3T8lq002535; Wed, 21 Jul 2004 23:29:08 -0400 (EDT) To: Bruce Momjian Cc: Mark Kirkwood , Simon Riggs , pgsql-admin@postgresql.org Subject: Re: [HACKERS] Point in Time Recovery In-reply-to: <200407220306.i6M36MU11209@candle.pha.pa.us> References: <200407220306.i6M36MU11209@candle.pha.pa.us> Comments: In-reply-to Bruce Momjian message dated "Wed, 21 Jul 2004 23:06:22 -0400" Date: Wed, 21 Jul 2004 23:29:08 -0400 Message-ID: <2534.1090466948@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200407/243 X-Sequence-Number: 14311 Bruce Momjian 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