Re: pg_start_backup without checkpoint patch (a part of Synch Rep)

From: "Fujii Masao" <masao(dot)fujii(at)gmail(dot)com>
To: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_start_backup without checkpoint patch (a part of Synch Rep)
Date: 2008-12-29 17:40:35
Message-ID: 3f0b79eb0812290940i4712f92cv63ce89fdb533b671@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, Dec 29, 2008 at 6:08 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Fujii Masao wrote:
>>
>> Attached is the self-contained patch to skip checkpoint at
>> pg_start_backup.
>> This is a part of Synch Rep patches, and was discussed in the following
>> thread.
>>
>> http://archives.postgresql.org/message-id/3f0b79eb0812240710j7e613f3atfd6b6fc27403546e@mail.gmail.com
>
> I'm not convinced that this is necessary for the replication patch. It is an
> orthogonal, new feature, and should be considered for 8.5, IMHO.

Synch Rep forces online-backup in some scenes (e.g. catchup after failover),
so I've argued from the beginning that the cost of it should be reduced.
I think this patch is one of the solutions to that problem.

>
>> Specifically, pg_start_backup uses the last checkpoint instead of doing a
>> new checkpoint if full_page_writes = on since the last checkpoint, which
>> guarantees that all the full-pages required for PITR are written.
>
> That assumes that the DBA has kept all the WAL segments that have been
> archived since last checkpoint. So this would no longer be safe:
>
> 1. rm <archivedir>/*
> 2. SELECT pg_start_backup();
> 3. tar cvzf backup.tar.gz <datadir>
> 4. SELECT pg_stop_backup();

Umm... I can't believe that there is the DBA to carry out such unsafe
operation. If disk crash occurs between 1 and 2, a database might
not recover *regardless of this patch* because of some missing xlogs.
I don't think that the patch itself is unsafe. In this patch, the DBA
can still judge safely which file can be removed, from a backup history
file or the return value of pg_start_backup.

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 Michael Meskes 2008-12-29 17:42:43 Re: ecpg regression test failures caused by window functions patch
Previous Message Tom Lane 2008-12-29 17:35:47 Re: TODO items for window functions