Re: PITR - Bug or feature?

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Rafael Martinez <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PITR - Bug or feature?
Date: 2010-02-02 04:33:44
Message-ID: 3f0b79eb1002012033j6835cd90qe040787da03fe265@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, Feb 1, 2010 at 7:33 PM, Rafael Martinez
<r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no> wrote:
> The PITR backup history file named
> pg_xlog/000000010000003800000000.00000020.backup included this information:
> --------------------------------------------------------
> START WAL LOCATION: 38/20 (file 000000010000003800000000)
> STOP WAL LOCATION: 38/88 (file 000000010000003800000000)
> CHECKPOINT LOCATION: 38/20
> START TIME: 2010-02-01 07:20:05 CET
> LABEL:
> /usit/dbpg-research/pg_bck/PITR_data/PITRBASE-dbpg-research_v8.3.9_j10_2010-02-01_072001
> STOP TIME: 2010-02-01 07:22:42 CET
> --------------------------------------------------------
>
> As you can see, the second number in START/STOP and CHECKPOINT LOCATION
> has a length of 2. This second number usually has a length of 8.
>
> I have checked the logs from our last 5000 PITR jobs and the format of
> these values has always been "<some number>/<8 digits number>"
>
> We have been using the "<some number>/<8 digits>" ID returned by the
> pg_start_backup() function to find out the PITR backup history file we
> have to wait for in the archive directory, before we can delete old WAL
> files that are not needed anymore. This task gets more complicated if we
> cannot trust to get a consistent format from pg_start_backup().
>
> These are some thoughts that may help to debug this issue:
>
> * The postgresql version with this 'problem' is 8.3.9
> * The active WAL ID when we started and stopped PITR ends with '00'
> * We have not seen this change of format in 8.3.9 when the WAL ID does
>  not ends with '00'
> * We have had WAL files ending with '00' with versions < 8.3.9 and the
>  format used have been the expected ("<some number>/<8 digits>").
>
> 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()? Those
functions convert the WAL location regardless of a format into the file name.
http://www.postgresql.org/docs/8.3/static/functions-admin.html#FUNCTIONS-ADMIN-BACKUP-TABLE

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2010-02-02 04:40:14 Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without
Previous Message KaiGai Kohei 2010-02-02 02:55:17 Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns