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

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

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, 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 12:09:57
Message-ID: 496F2795.70105@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-docspgsql-hackers
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 <jisbell(at)cisco(dot)com> wrote:
>>> The following bug has been logged online:
>>>
>>> Bug reference:      4566
>>> Logged by:          Randy Isbell
>>> Email address:      jisbell(at)cisco(dot)com
>>> 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 (pgsql-bugs(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-bugs
> 


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

In response to

Responses

pgsql-docs by date

Next:From: Fujii MasaoDate: 2009-01-15 14:15:55
Subject: Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION
Previous:From: Bruce MomjianDate: 2009-01-15 01:50:31
Subject: Re: BUG #4566: pg_stop_backup() reports incorrect STOP WAL LOCATION

pgsql-hackers by date

Next:From: Merlin MoncureDate: 2009-01-15 12:52:33
Subject: Re: fire trigger for a row without update?
Previous:From: Grzegorz JaƛkiewiczDate: 2009-01-15 10:23:34
Subject: Re: inconsistency in aliasing

pgsql-bugs by date

Next:From: Said NoucairDate: 2009-01-15 13:36:04
Subject: BUG #4616: Create Database with another encoding as the encoding from postgres
Previous:From: Oleg BartunovDate: 2009-01-15 06:19:49
Subject: Re: BUG #4562: ts_headline() adds space when parsing url

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