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

Re: Streaming replication, retrying from archive

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication, retrying from archive
Date: 2010-01-14 16:28:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Jan 15, 2010 at 12:23 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> If we don't fix that within the server, we will need to document that
> caveat and every installation will need to work around that one way or
> another. Maybe with some monitoring software and an automatic restart. Ugh.
> I wasn't really asking if it's possible to fix, I meant "Let's think
> about *how* to fix that".

OK. How about the following (though it's a rough design)?

(1)    If walsender cannot read the WAL file because of ENOENT, it sends the
         special message indicating that error to walreceiver. This message is
         shipped on the COPY protocol.

(2-a) If the message arrives, walreceiver exits by using proc_exit().
(3-a) If the startup process detects the exit of walreceiver in
          it switches back to a normal archive recovery mode, closes
the currently opened
          WAL file, resets some variables (readId, readSeg, etc), and
calls FetchRecord()
          again. Then it tries to restore the WAL file from the
archive if the restore_command
          is supplied, and switches to a streaming recovery mode again
if invalid WAL is


(2-b) If the message arrives, walreceiver executes restore_command,
and then sets
          the receivedUpto to the end location of the restored WAL
file. The restored file is
          expected to be filled because it doesn't exist in the
primary's pg_xlog. So that
          update of the receivedUpto is OK.
(3-b) After one WAL file is restored, walreceiver tries to connect to
the primary, and
          starts replication again. If the ENOENT error occurs again,
we go back to the (1).

I like the latter approach since it's simpler. Thought?


Fujii Masao
NTT Open Source Software Center

In response to


pgsql-hackers by date

Next:From: Fujii MasaoDate: 2010-01-14 16:43:51
Subject: Re: Streaming replication, retrying from archive
Previous:From: Tim BunceDate: 2010-01-14 16:07:16
Subject: Miscellaneous changes to plperl [PATCH]

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