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

Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Date: 2010-02-10 05:05:55
Message-ID: 3f0b79eb1002092105r21e009d3v468496058ba04392@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-docspgsql-hackers
On Thu, Jan 28, 2010 at 12:27 AM, Heikki Linnakangas
<heikki(at)postgresql(dot)org> wrote:
> Log Message:
> -----------
> Make standby server continuously retry restoring the next WAL segment with
> restore_command, if the connection to the primary server is lost. This
> ensures that the standby can recover automatically, if the connection is
> lost for a long time and standby falls behind so much that the required
> WAL segments have been archived and deleted in the master.
>
> This also makes standby_mode useful without streaming replication; the
> server will keep retrying restore_command every few seconds until the
> trigger file is found. That's the same basic functionality pg_standby
> offers, but without the bells and whistles.

http://archives.postgresql.org/pgsql-hackers/2010-01/msg01520.php
http://archives.postgresql.org/pgsql-hackers/2010-01/msg02589.php

As I pointed out previously, the standby might restore a partially-filled
WAL file that is being archived by the primary, and cause a FATAL error.
And this happened in my box when I was testing the SR.

  sby [20088] FATAL:  archive file "000000010000000000000087" has
wrong size: 14139392 instead of 16777216
  sby [20076] LOG:  startup process (PID 20088) exited with exit code 1
  sby [20076] LOG:  terminating any other active server processes
  act [18164] LOG:  received immediate shutdown request

If the startup process is in standby mode, I think that it should retry
starting replication instead of emitting an error when it finds a
partially-filled file in the archive. Then if the replication has been
terminated, it has only to restore the archived file again. Thought?

Regards,

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

In response to

Responses

pgsql-docs by date

Next:From: Heikki LinnakangasDate: 2010-02-10 07:32:48
Subject: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Previous:From: Jaime CasanovaDate: 2010-02-06 18:17:14
Subject: not english bug reports

pgsql-hackers by date

Next:From: Priit LaesDate: 2010-02-10 06:45:47
Subject: [PATCH] Output configuration status after ./configure run.
Previous:From: Takahiro ItagakiDate: 2010-02-10 04:48:55
Subject: pg_restore --single-transaction and --clean

pgsql-committers by date

Next:From: Heikki LinnakangasDate: 2010-02-10 07:32:48
Subject: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Previous:From: Tom LaneDate: 2010-02-10 03:38:35
Subject: pgsql: Improve planner's choices about when to use hashing vs sorting

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