Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Date
Msg-id 3f0b79eb1002180337t1fab1395ve3491256672af15f@mail.gmail.com
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
List pgsql-hackers
On Fri, Feb 12, 2010 at 2:29 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> So the only major feature we're missing is the ability to clean up old
> files.

I found another missing feature in new file-based log shipping (i.e.,
standby_mode is enabled and 'cp' is used as restore_command).

After the trigger file is found, the startup process with pg_standby
tries to replay all of the WAL files in both pg_xlog and the archive.
So, when the primary fails, if the latest WAL file in pg_xlog of the
primary can be read, we can prevent the data loss by copying it to
pg_xlog of the standby before creating the trigger file.

On the other hand, the startup process with standby mode doesn't
replay the WAL files in pg_xlog after the trigger file is found. So
failover always causes the data loss even if the latest WAL file can
be read from the primary. And if the latest WAL file is copied to the
archive instead, it can be replayed but a PANIC error would happen
because it's not filled.

We should remove this restriction?

Regards,

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


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Streaming replication on win32, still broken
Next
From: Robert Haas
Date:
Subject: Re: A thought: should we run pgindent now?