Re: For what should pg_stop_backup wait?

From: "Fujii Masao" <masao(dot)fujii(at)gmail(dot)com>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: For what should pg_stop_backup wait?
Date: 2008-08-08 02:47:03
Message-ID: 3f0b79eb0808071947o1f70c19fj89e919851fe80448@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 7, 2008 at 11:34 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> On Thu, 2008-08-07 at 14:59 +0100, Simon Riggs wrote:
>
>> I'll do a patch. Thanks for your input.
>
> Please review attached patch.

Thank you for your patch!

But, there are two problems in this patch, I think.

> ! * Wait until the last WAL file has been archived. We assume that the
> ! * alphabetic sorting property of the WAL files ensures the history
> ! * file is guaranteed archived by the time the last WAL file is archived.
> ! * The history file name depends upon the startpoint, whereas the last
> ! * file depends upon the stoppoint. They are always different because we
> ! * make an explicit xlog switch earlier in this function.

If there are a few transactions during backup, startpoint may be the same as
the stoppoint.

postgres=# SELECT pg_xlogfile_name(pg_start_backup('test')) AS startpoint;
startpoint
--------------------------
000000010000000000000004
(1 row)

*** A few transaction occurs ***

postgres=# SELECT pg_xlogfile_name(pg_stop_backup()) AS stoppoint;
stoppoint
--------------------------
000000010000000000000004
(1 row)

In this situation, the history file (000000010000000000000004.00000020.backup)
is behind the stoppoint (000000010000000000000004) in the alphabetic order.
So, pg_stop_backup should wait for both the stoppoint and the history
file, I think.

> ! while (!XLogArchiveCheckDone(stopxlogfilename, false))

If a concurrent checkpoint removes the status file before XLogArchiveCheckDone,
pg_stop_backup continues waiting forever. This is undesirable behavior.
Yes, statement_timeout may help. But, I don't want to use it, because the
*successful* backup is canceled.

How about checking whether the stoppoint was archived by comparing with
the last WAL archived. The archiver process can tell the last WAL archived.
Or, we can calculate it from the status file.

On the other hand, pg_stop_backup doesn't continue waiting for the history file
forever. Because, only pg_stop_backup removes the status file of it,
and a concurrent
pg_stop_backup never happen.

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 Amit jain 2008-08-08 06:31:40 Re: [HACKERS] pg_restore -d cipa /cipa/RAJASTHAN/RAJASTHAN/CIPABACKUP01_08_2008.TAR pg_restore: [archiver] out of memory
Previous Message Robert Haas 2008-08-08 01:41:16 Re: patch: Add columns via CREATE OR REPLACE VIEW