Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 3E148632BF7 for ; Tue, 16 Feb 2010 01:19:27 -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 39716-10 for ; Tue, 16 Feb 2010 05:19:16 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mail.postgresql.org (Postfix) with ESMTP id AAAA6632BC5 for ; Tue, 16 Feb 2010 01:19:16 -0400 (AST) Received: by gxk10 with SMTP id 10so4565135gxk.3 for ; Mon, 15 Feb 2010 21:19:16 -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:cc:content-type; bh=IU2xSCPfgI0X9fvAhlqXsR7SLJhfNjVz8VPL6RXG3iY=; b=uv6B2nqQmumNUu3F5ylkuvsvC0W191DoWdXaLa85v//qSZfNkQ4fEMVeA5qVUxAvV9 XEH3qzwQAgdXPuZ8nUDV1aj4v+u5Srsj7xyLLAXzSsKi3XnhNt2QdOh4LX/kCUXX7+Sk v3DPhvXbV9kaM890PXqO5S90B7vbL4PbSJtVw= 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 :cc:content-type; b=YlByagS/F2YT9iHF8emNUwu3GEVdM9VwZFgQwzVROLYrj1B2Kffq6HHKCvKj1j4lyQ NsBb7+9F+tOwiYa5UF/xOmP9UXWj8XEVISjFcM8IKCeQtNHcrRh0Dcnf5owAo6W07QkT dCK9nfCMTMuLqvowEzdl/PgtrMz/vEcezxcxo= MIME-Version: 1.0 Received: by 10.101.214.5 with SMTP id r5mr470125anq.206.1266297555905; Mon, 15 Feb 2010 21:19:15 -0800 (PST) In-Reply-To: <20100205090834.9BE7.52131E4D@oss.ntt.co.jp> References: <200812051441.mB5EfG1M007309@wwwmaster.postgresql.org> <3f0b79eb1002032328s46af0dcer64692245d3d94210@mail.gmail.com> <20100205090834.9BE7.52131E4D@oss.ntt.co.jp> Date: Tue, 16 Feb 2010 14:19:15 +0900 Message-ID: <3f0b79eb1002152119m2be4a818x4b72172d27892f@mail.gmail.com> Subject: Re: Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION From: Fujii Masao To: Takahiro Itagaki Cc: PostgreSQL-development Content-Type: multipart/mixed; boundary=001636c92902ffebf1047fb0dfe5 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/1288 X-Sequence-Number: 157631 --001636c92902ffebf1047fb0dfe5 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 5, 2010 at 9:08 AM, Takahiro Itagaki wrote: > > Fujii Masao wrote: > >> 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. >> > >> > START WAL LOCATION: 10/FE1E2BAC (file 0000000200000010000000FE) >> > STOP WAL LOCATION: 10/FF000000 (file 0000000200000010000000FF) > >> But it was rejected because its change might break the existing app. > > It might break existing applications if it returns "FE" instead of "FF", > but never-used filename surprises users. (IMO, the existing apps probably > crash if "FF" returned, i.e, 1/256 of the time.) > > Should it return the *next* reasonable log filename instead of "FF"? > For example, 000000020000002000000000 for the above case. Here is the patch that avoids a nonexistent file name, according to Itagaki-san's suggestion. If we are crossing a logid boundary, the next reasonable file name is used instead of a nonexistent one. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center --001636c92902ffebf1047fb0dfe5 Content-Type: text/x-patch; charset=US-ASCII; name="stop_file_name_0216.patch" Content-Disposition: attachment; filename="stop_file_name_0216.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g5q8q4ru0 KioqIGEvc3JjL2JhY2tlbmQvYWNjZXNzL3RyYW5zYW0veGxvZy5jCi0tLSBiL3NyYy9iYWNrZW5k L2FjY2Vzcy90cmFuc2FtL3hsb2cuYwoqKioqKioqKioqKioqKioKKioqIDgwNTcsODA2MyAqKioq IHBnX3N0b3BfYmFja3VwKFBHX0ZVTkNUSU9OX0FSR1MpCiAgCSAqLwogIAlSZXF1ZXN0WExvZ1N3 aXRjaCgpOwogIAohIAlYTEJ5dGVUb1NlZyhzdG9wcG9pbnQsIF9sb2dJZCwgX2xvZ1NlZyk7CiAg CVhMb2dGaWxlTmFtZShzdG9weGxvZ2ZpbGVuYW1lLCBUaGlzVGltZUxpbmVJRCwgX2xvZ0lkLCBf bG9nU2VnKTsKICAKICAJLyogVXNlIHRoZSBsb2cgdGltZXpvbmUgaGVyZSwgbm90IHRoZSBzZXNz aW9uIHRpbWV6b25lICovCi0tLSA4MDU3LDgwNzggLS0tLQogIAkgKi8KICAJUmVxdWVzdFhMb2dT d2l0Y2goKTsKICAKISAJaWYgKHN0b3Bwb2ludC54cmVjb2ZmID49IFhMb2dTZWdTaXplKQohIAl7 CiEgCQlYTG9nUmVjUHRyCXJlY3B0ciA9IHN0b3Bwb2ludDsKISAKISAJCS8qCiEgCQkgKiBTaW5j ZSB4bG9nIHNlZ21lbnQgZmlsZSBuYW1lIGlzIGNhbGN1bGF0ZWQgYnkgdXNpbmcgWExCeXRlVG9T ZWcsCiEgCQkgKiBpdCBtaWdodCBpbmRpY2F0ZSBhIG5vbmV4aXN0ZW50IGZpbGUgKGkuZS4sIHdo aWNoIGVuZHMgaW4gIkZGIikKISAJCSAqIHdoZW4gd2UgYXJlIGNyb3NzaW5nIGEgbG9naWQgYm91 bmRhcnkuIEluIHRoaXMgY2FzZSwgd2UgdXNlIHRoZQohIAkJICogbmV4dCByZWFzb25hYmxlIGZp bGUgbmFtZSBpbnN0ZWFkIG9mIG5vbmV4aXN0ZW50IG9uZS4KISAJCSAqLwohIAkJcmVjcHRyLnhs b2dpZCArPSAxOwohIAkJcmVjcHRyLnhyZWNvZmYgPSBYTE9HX0JMQ0tTWjsKISAJCVhMQnl0ZVRv U2VnKHJlY3B0ciwgX2xvZ0lkLCBfbG9nU2VnKTsKISAJfQohIAllbHNlCiEgCQlYTEJ5dGVUb1Nl ZyhzdG9wcG9pbnQsIF9sb2dJZCwgX2xvZ1NlZyk7CiAgCVhMb2dGaWxlTmFtZShzdG9weGxvZ2Zp bGVuYW1lLCBUaGlzVGltZUxpbmVJRCwgX2xvZ0lkLCBfbG9nU2VnKTsKICAKICAJLyogVXNlIHRo ZSBsb2cgdGltZXpvbmUgaGVyZSwgbm90IHRoZSBzZXNzaW9uIHRpbWV6b25lICovCg== --001636c92902ffebf1047fb0dfe5--