Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Randy Isbell <jisbell(at)cisco(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
Date: 2009-01-15 15:23:46
Message-ID: 496F5502.4020907@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-docs pgsql-hackers

Fujii Masao wrote:
> On Thu, Jan 15, 2009 at 9:09 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> 1. The proposed patch would remove the "+ 1". Seems like an unnecessary API
>> change, and I don't recall any reason why the new definition would be
>> better.
>
> My patch doesn't change the return value of pg_stop_backup(), it's still
> the same as the return value of pg_switch_xlog().

Oh, ok.

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

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.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2009-01-15 16:15:41 Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
Previous Message Heikki Linnakangas 2009-01-15 14:25:29 Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION

Browse pgsql-docs by date

  From Date Subject
Next Message Tom Lane 2009-01-15 16:15:41 Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
Previous Message Heikki Linnakangas 2009-01-15 14:25:29 Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2009-01-15 15:36:29 Re: tuplestore potential performance problem
Previous Message Jaime Casanova 2009-01-15 15:07:42 Re: New patch for Column-level privileges