Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id C539B6326B6 for ; Thu, 4 Feb 2010 03:28:15 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 90222-07 for ; Thu, 4 Feb 2010 07:28:05 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-yx0-f188.google.com (mail-yx0-f188.google.com [209.85.210.188]) by mail.postgresql.org (Postfix) with ESMTP id 2B39E63014E for ; Thu, 4 Feb 2010 03:28:05 -0400 (AST) Received: by yxe26 with SMTP id 26so2076788yxe.28 for ; Wed, 03 Feb 2010 23:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=AYa6DopQCbyD5jtKnywVA7clM4ozwPdCvfa/ltU4O+0=; b=Ro1w/cOIuv/CMoGgfIw6+YDZDEDoVFURd6XbVtiV7KGkMd12lKIUDoS38t2ygAr/2Z 2PlzuF7hZ3drmX5GxIPPCG2rFAVC34OvWPLmnSJZCb4CsmSqHIpsMfEtWOC/h+E3NenS xCroxZcIBZTQwdxD0WiNbt3fw5jb9lysBLj74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=jawq1oTPJpwSu/Qdlk5Bg2AVbF9DZ7WKg+briwm2g5tXPFK9pITmV/TY3o0Hg93REA ww5hKdRx31ymu8wI+XEJxYKclIH77qw00Bqt3j4Zm/CH+QyOTizkBzf5EE26ttb+5OOX jlpRZzbrm0jEfgbHIBzAahtriqyE5sA8EdLiI= MIME-Version: 1.0 Received: by 10.101.207.28 with SMTP id j28mr825798anq.193.1265268484065; Wed, 03 Feb 2010 23:28:04 -0800 (PST) In-Reply-To: <200812051441.mB5EfG1M007309@wwwmaster.postgresql.org> References: <200812051441.mB5EfG1M007309@wwwmaster.postgresql.org> Date: Thu, 4 Feb 2010 16:28:03 +0900 Message-ID: <3f0b79eb1002032328s46af0dcer64692245d3d94210@mail.gmail.com> Subject: Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION From: Fujii Masao To: PostgreSQL-development Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5 tests=BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201002/304 X-Sequence-Number: 156647 On Fri, Dec 5, 2008 at 11:41 PM, Randy Isbell wrote: > An inconsistency exists between the segment name reported by > pg_stop_backup() and the actual WAL file name. > > > SELECT pg_start_backup('filename'); > =A0 =A0 =A0 =A0 pg_start_backup > =A0 =A0 =A0 =A0----------------- > =A0 =A0 =A0 =A0 10/FE1E2BAC > =A0 =A0 =A0 =A0(1 row) > > Later: > SELECT pg_stop_backup(); > =A0 =A0 =A0 =A0 pg_stop_backup > =A0 =A0 =A0 =A0---------------- > =A0 =A0 =A0 =A0 10/FF000000 > =A0 =A0 =A0 =A0(1 row) > > The resulting *.backup file: > > START WAL LOCATION: 10/FE1E2BAC (file 0000000200000010000000FE) > STOP WAL LOCATION: 10/FF000000 (file 0000000200000010000000FF) > CHECKPOINT LOCATION: 10/FE1E2BAC > START TIME: 2008-11-09 01:15:06 CST > LABEL: /bck/db/sn200811090115.tar.gz > STOP TIME: 2008-11-09 01:15:48 CST > > In my 8.3.4 instance, WAL file naming occurs as: > > ... > 0000000100000003000000FD > 0000000100000003000000FE > 000000010000000400000000 > 000000010000000400000001 > ... > > WAL files never end in 'FF'. =A0This causes a problem when trying to coll= ect > the ending WAL file for backup. Sorry for resurrecting an old argument. http://archives.postgresql.org/message-id/200812051441.mB5EfG1M007309@wwwma= ster.postgresql.org I got the complaint about this behavior of the current pg_stop_backup() in this morning. I thought that this is the bug, and created the patch. But it was rejected because its change might break the existing app. Though I'm not sure if there is really such an app. Anyway I think that something like the following statements should be added into the document. Thought? ------------ Note that the WAL file name in the backup history file cannot be used to determine which WAL files are required for the backup. Because it indicates the subsequent WAL file of the starting or ending one for the backup, when its location is exactly at a WAL file boundary (What is worse, sometimes it indicates a nonexistent WAL file). ------------ Regards, --=20 Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center