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

Re: PITR - Bug or feature?

From: Rafael Martinez <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PITR - Bug or feature?
Date: 2010-02-03 09:46:13
Message-ID: 4B6945E5.40609@usit.uio.no (view raw or flat)
Thread:
Lists: pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fujii Masao wrote:
> On Mon, Feb 1, 2010 at 7:33 PM, Rafael Martinez
> <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no> wrote:

>>
>> Any thoughts about this? Is this a bug or a 'feature'?
> 
> This is not a bug. Since pg_start_backup() uses "%X/%X" (not "%08X/%08X")
> as the format of WAL location, the length of the second number of the WAL
> location could be less than 8.
> 
> Instead of calculating the name of the backup history file for yourself,
> how about using pg_xlogfile_name() or pg_xlogfile_name_offset()? 

Thanks for the answer. We have updated our code and started using
pg_xlogfile_name() in our PITR script. Everything works perfect now.

When we started using PITR with version 8.1, we didn't have these
functions and that was the reason we were using the value returned by
pg_start_backup() to find out the last WAL to keep after PITR was finnish.

regards,
- --
 Rafael Martinez, <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>
 Center for Information Technology Services
 University of Oslo, Norway

 PGP Public Key: http://folk.uio.no/rafael/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)

iD8DBQFLaUXLBhuKQurGihQRAqNpAKCLCc6MDhGONJi5fTgStFoC+PP6hgCdHqVC
yDfsC1erRWxFJRCF305Bbg8=
=Brbz
-----END PGP SIGNATURE-----

In response to

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-02-03 09:47:39
Subject: Re: Streaming replication and message type header
Previous:From: Joachim WielandDate: 2010-02-03 09:34:07
Subject: Re: Listen / Notify - what to do when the queue is full

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