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:content-transfer-encoding;
	b=r1IwKmdc6lvKtOdhpTG7Wbr0EIVWiU4UeNVPpiRRdjoVy2/6/wBPLilybaGADxfw8J
	6xtIjwIvD61JMALXNiUIIeTnOcUH6Ht58BfIOzIJfAGFDuomBxa05VVK/e+p0D8jFoaP
	5KyjJHNetmEdM9Zl680FQGIkddb8LqoIedkdc=
MIME-Version: 1.0
In-Reply-To: <496F5502.4020907@enterprisedb.com>
References: <200901150150.n0F1oV113850@momjian.us>
	<496F2795.70105@enterprisedb.com>
	<3f0b79eb0901150615g133f845erc39faf19793d5977@mail.gmail.com>
	<496F5502.4020907@enterprisedb.com>
Date: Fri, 16 Jan 2009 11:18:49 +0900
Message-ID: <3f0b79eb0901151818q51710cd6pc363391614628c07@mail.gmail.com>
Subject: Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
From: Fujii Masao <masao.fujii@gmail.com>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Bruce Momjian <bruce@momjian.us>, Randy Isbell <jisbell@cisco.com>,
	pgsql-bugs@postgresql.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi,

On Fri, Jan 16, 2009 at 12:23 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
>> Only a part of backup
>> history file (the file name including stop wal location) is changed.
>> Currently, the file name is wrong if stop wal location indicates a
>> boundary
>> byte. This would confuse the user, I think.
>
> Hmm, I guess that would make it less confusing. Seems quite dangerous to
> change the meaning now, however :-(. A program (or person) that knows its
> current meaning would currently wait for STOP WAL filename - 1 file to be
> archived. If we change the meaning, the same program would determine that
> the backup is safe, even if the last xlog file hasn't yet been archived. So
> I think this is not back-portable.

Yes, I agree that we need to be careful about changing such meaning.
But, there are two reasons why I think this would confuse the users.

1.
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?

2.
I think it's odd that the return value of pg_xlogfile_name(pg_stop_backup())
is different from the wal stop filename in backup history file, though
the return value of pg_stop_backup() is the same as the wal stop location
in backup history file. We should uniform them? pg_xlogfile_name() always
returns the inclusive filename, so the users don't need to care about
whether the return value of pg_stop_backup() indicates a boundary byte.
This is already documented.

-----------------
http://www.postgresql.org/docs/current/static/functions-admin.html

> Similarly, pg_xlogfile_name extracts just the transaction log file name.
> When the given transaction log location is exactly at a transaction log file
> boundary, both these functions return the name of the preceding transaction
> log file. This is usually the desired behavior for managing transaction log
> archiving behavior, since the preceding file is the last one that currently
> needs to be archived.
-----------------

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center