From: Bruce Momjian <bruce@momjian.us>
Message-Id: <200901151743.n0FHh6f16596@momjian.us>
Subject: Re: BUG #4566: pg_stop_backup() reports incorrect STOP
 WAL LOCATION
In-Reply-To: <1232040824.31921.76.camel@ebony.2ndQuadrant>
To: Simon Riggs <simon@2ndQuadrant.com>
Date: Thu, 15 Jan 2009 12:43:06 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
	Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	Fujii Masao <masao.fujii@gmail.com>, Randy Isbell <jisbell@cisco.com>,
	pgsql-bugs@postgresql.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"

Simon Riggs wrote:
> 
> On Thu, 2009-01-15 at 11:15 -0500, Tom Lane wrote:
> > Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> > > Fujii Masao 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.
> > 
> > > Should we change it in HEAD? I'm leaning towards no, on the grounds that 
> > > tools/people would then have to know the version it's dealing with to 
> > > interpret the value correctly, and because pg_stop_backup() now waits 
> > > for the last xlog file to be archived before returning, there's little 
> > > need to look at that file.
> > 
> > I agree.  It might have been better to define it the other way
> > originally, but the risks of changing it now outweigh any likely
> > benefit.
> 
> Agreed. It's too confusing the other way.
> 
> The manual entry wasn't changed from my original submission
> unfortunately.

OK, do you have updated wording?

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +