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 89B1732A1CF for ; Thu, 30 Sep 2004 17:09:23 +0100 (BST) 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 52617-06 for ; Thu, 30 Sep 2004 16:09:16 +0000 (GMT) Received: from news.hub.org (news.hub.org [200.46.204.72]) by svr1.postgresql.org (Postfix) with ESMTP id 38C0D32A030 for ; Thu, 30 Sep 2004 17:09:16 +0100 (BST) Received: from news.hub.org (news.hub.org [200.46.204.72]) by news.hub.org (8.12.9/8.12.9) with ESMTP id i8UG9G5a054076 for ; Thu, 30 Sep 2004 16:09:16 GMT (envelope-from news@news.hub.org) Received: (from news@localhost) by news.hub.org (8.12.9/8.12.9/Submit) id i8UFspTJ048899 for pgsql-admin@postgresql.org; Thu, 30 Sep 2004 15:54:51 GMT X-Newsgroups: comp.databases.postgresql.admin From: JEDIDIAH Subject: Re: [HACKERS] Point in Time Recovery References: <2534.1090466948@sss.pgh.pa.us> <200407281625.i6SGPak28629@candle.pha.pa.us> Message-ID: User-Agent: slrn/0.9.8.0 (Linux) Date: Thu, 30 Sep 2004 10:54:50 -0500 Lines: 30 X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.16 To: pgsql-admin@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.1 tagged_above=0.0 required=5.0 tests=NO_DNS_FOR_FROM X-Spam-Level: * X-Archive-Number: 200410/12 X-Sequence-Number: 15006 On 2004-07-28, Bruce Momjian wrote: > > Here is another open PITR issue that I think will have to be addressed > in 7.6. If you do a critical transaction, but do nothing else for eight > hours, that critical transaction hasn't been archived yet. It is still > sitting in pg_xlog until the WAL file fills. > > I think we will need to document this behavior and address it in some > way in 7.6. We can't assume that we can send multiple copies of pg_xlog > to the archive (partial and full ones) because we might be going to a If a particular transaction is so important that it absolutely positively needs to be archived offline for PITR, then why not just mark it that way or allow for the application to trigger archival of this critical REDO? > tape drive. However, this is a non-intuitive behavior of our archiver. > We might need to tell people to archive the most recent WAL file every > minute to some other location or something. [deletia] -- Negligence will never equal intent, no matter how you attempt to distort reality to do so. This is what separates ||| the real butchers from average Joes (or Fritzes) caught up in / | \ events not in their control.