Skip site navigation (1) Skip section navigation (2)

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

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(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-16 02:18:49
Message-ID: 3f0b79eb0901151818q51710cd6pc363391614628c07@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-docspgsql-hackers
Hi,

On Fri, Jan 16, 2009 at 12:23 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Responses

pgsql-docs by date

Next:From: Tom LaneDate: 2009-01-16 02:42:23
Subject: Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
Previous:From: Bruce MomjianDate: 2009-01-15 23:54:03
Subject: Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-01-16 02:42:23
Subject: Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
Previous:From: Robert HaasDate: 2009-01-16 02:09:11
Subject: Re: FWD: Re: Updated backslash consistency patch

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-01-16 02:42:23
Subject: Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
Previous:From: Hiroshi SaitoDate: 2009-01-16 02:14:30
Subject: BUG #4619: pg_ctl reports strange error message when be executed on non executable directory

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group