Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 0E7B66323BF for ; Thu, 15 Jan 2009 22:42:35 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 28320-02 for ; Thu, 15 Jan 2009 22:42:31 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 224846322E8 for ; Thu, 15 Jan 2009 22:42:30 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id n0G2gNDT000234; Thu, 15 Jan 2009 21:42:23 -0500 (EST) To: Fujii Masao cc: Heikki Linnakangas , Bruce Momjian , Randy Isbell , pgsql-bugs@postgresql.org Subject: Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION In-reply-to: <3f0b79eb0901151818q51710cd6pc363391614628c07@mail.gmail.com> References: <200901150150.n0F1oV113850@momjian.us> <496F2795.70105@enterprisedb.com> <3f0b79eb0901150615g133f845erc39faf19793d5977@mail.gmail.com> <496F5502.4020907@enterprisedb.com> <3f0b79eb0901151818q51710cd6pc363391614628c07@mail.gmail.com> Comments: In-reply-to Fujii Masao message dated "Fri, 16 Jan 2009 11:18:49 +0900" Date: Thu, 15 Jan 2009 21:42:23 -0500 Message-ID: <233.1232073743@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200901/106 X-Sequence-Number: 22088 Fujii Masao writes: > Currently, stop wal filename is not always exclusive. If stop wal location > doesn't indicate a boundary byte, its filename is inclusive. I'm afraid that > the users cannot easily judge which "filename - 1" or "filename" should be > waited. I mean that the users need to calculate whether stop wal location > indicates a boundary byte or not before starting waiting. Such calculation > should be done by the users? No, which is why we provide functions to do it ;-) It's really not worth changing the file contents. We're far more likely to hear complaints like "you broke my archive script and I lost all my data" than compliments about "the contents of this internal implementation file are lots more sensible now". regards, tom lane