Received: from maia.hub.org (unknown [200.46.208.211])
	by mail.postgresql.org (Postfix) with ESMTP id 0CA47632E83
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Wed, 17 Feb 2010 13:07:51 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia,
	port 10024) with ESMTP id 23884-01
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Wed, 17 Feb 2010 17:07:39 +0000 (UTC)
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 27CC4632E19
	for <pgsql-hackers@postgresql.org>;
	Wed, 17 Feb 2010 13:07:40 -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 o1HH7YXL028370;
	Wed, 17 Feb 2010 12:07:34 -0500 (EST)
To: Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
	Fujii Masao <masao.fujii@gmail.com>
Subject: Re: Re: [BUGS] BUG #4566: pg_stop_backup() reports incorrect STOP WAL
	LOCATION
In-reply-to: <20100217174319.A5C1.52131E4D@oss.ntt.co.jp> 
References: <20100205090834.9BE7.52131E4D@oss.ntt.co.jp>
	<3f0b79eb1002152119m2be4a818x4b72172d27892f@mail.gmail.com>
	<20100217174319.A5C1.52131E4D@oss.ntt.co.jp>
Comments: In-reply-to Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>
	message dated "Wed, 17 Feb 2010 17:43:19 +0900"
Date: Wed, 17 Feb 2010 12:07:34 -0500
Message-ID: <28369.1266426454@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-2.465 tagged_above=-10 required=5 tests=AWL=0.134,
	BAYES_00=-2.599
X-Spam-Level: 
X-Archive-Number: 201002/1447
X-Sequence-Number: 157790

Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp> writes:
> I'd like to apply the patch to HEAD and previous releases because
> the issue seems to be a bug in the core. Any comments or objections?

The proposed patch seems quite ugly to me; not only the messy coding,
but the fact that it might return either the segment containing the
XLOG_BACKUP_END record or the next one.

I think an appropriate fix might just be s/XLByteToSeg/XLByteToPrevSeg/,
so that the result is always the segment containing the XLOG_BACKUP_END
record even when the record ends exactly at a segment boundary.

			regards, tom lane