public inbox for [email protected]
help / color / mirror / Atom feedFrom: Heikki Linnakangas <[email protected]>
To: Bruce Momjian <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: Randy Isbell <[email protected]>
Cc: [email protected]
Subject: Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
Date: Thu, 15 Jan 2009 14:09:57 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
I think not
(http://archives.postgresql.org/pgsql-hackers/2008-12/msg00126.php). The
return value of pg_stop_backup() is currently the same as
pg_switch_xlog()'s: the location of the last byte before the XLOG switch
+ 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.
A fix for the broken waiting behavior discussed in that thread was
committed.
Bruce Momjian wrote:
> Would someone please tell me if this should be applied?
>
> ---------------------------------------------------------------------------
>
> Fujii Masao wrote:
>> On Fri, Dec 5, 2008 at 11:41 PM, Randy Isbell <[email protected]> wrote:
>>> The following bug has been logged online:
>>>
>>> Bug reference: 4566
>>> Logged by: Randy Isbell
>>> Email address: [email protected]
>>> PostgreSQL version: 8.3.4
>>> Operating system: FreeBSD 6.2
>>> Description: pg_stop_backup() reports incorrect STOP WAL LOCATION
>>> Details:
>>>
>>> An inconsistency exists between the segment name reported by
>>> pg_stop_backup() and the actual WAL file name.
>>>
>>>
>>> SELECT pg_start_backup('filename');
>>> pg_start_backup
>>> -----------------
>>> 10/FE1E2BAC
>>> (1 row)
>>>
>>> Later:
>>> SELECT pg_stop_backup();
>>> pg_stop_backup
>>> ----------------
>>> 10/FF000000
>>> (1 row)
>>>
>>> The resulting *.backup file:
>>>
>>> START WAL LOCATION: 10/FE1E2BAC (file 0000000200000010000000FE)
>>> STOP WAL LOCATION: 10/FF000000 (file 0000000200000010000000FF)
>>> CHECKPOINT LOCATION: 10/FE1E2BAC
>>> START TIME: 2008-11-09 01:15:06 CST
>>> LABEL: /bck/db/sn200811090115.tar.gz
>>> STOP TIME: 2008-11-09 01:15:48 CST
>>>
>>> In my 8.3.4 instance, WAL file naming occurs as:
>>>
>>> ...
>>> 0000000100000003000000FD
>>> 0000000100000003000000FE
>>> 000000010000000400000000
>>> 000000010000000400000001
>>> ...
>>>
>>> WAL files never end in 'FF'. This causes a problem when trying to collect
>>> the ending WAL file for backup.
>> It's a bug of pg_stop_backup(), which has been talked before.
>> http://archives.postgresql.org/pgsql-hackers/2008-12/msg00108.php
>>
>> Attached is a patch against HEAD. I think that we should
>> also backport.
>>
>> Regards,
>>
>> --
>> Fujii Masao
>> NIPPON TELEGRAPH AND TELEPHONE CORPORATION
>> NTT Open Source Software Center
>
> [ Attachment, skipping... ]
>
>> --
>> Sent via pgsql-bugs mailing list ([email protected])
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-bugs
>
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
view thread (22+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox