Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
Date
Msg-id 200901151743.n0FHh6f16596@momjian.us
Whole thread Raw
In response to Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
List pgsql-bugs
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. +

pgsql-bugs by date:

Previous
From: Simon Riggs
Date:
Subject: Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
Next
From: Simon Riggs
Date:
Subject: Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION