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

Re: Streaming replication, and walsender during recovery

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication, and walsender during recovery
Date: 2010-01-28 10:22:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Jan 28, 2010 at 4:47 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> I think there's a race condition at the end of recovery. When the
> shutdown checkpoint is written, with new TLI, doesn't a cascading
> walsender try to send that to the standby as soon as it's flushed to
> disk? But it won't find it in the WAL segment with the old TLI that it's
> reading.

Right. But I don't think that such a shutdown checkpoint record is worth
being sent by a cascading walsender. I think that such a walsender has
only to exit without regard to the WAL segment with the new TLI.

> Also, when segments are restored from the archive, using
> restore_command, the cascading walsender won't find them because they're
> not written in pg_xlog like normal WAL segments.

Yeah, I need to adjust my approach to the recent 'xlog-refactor' change.
The archived file needs to be restored without a name change, and remain
in pg_xlog until the bgwriter will have recycled it.

But that change would make the xlog.c even more complicated. Should we
postpone the 'cascading walsender' feature into v9.1, and, in v9.0, just
forbid walsender to be started during recovery?


Fujii Masao
NTT Open Source Software Center

In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-01-28 10:43:17
Subject: Re: Streaming replication, and walsender during recovery
Previous:From: Pavel StehuleDate: 2010-01-28 09:53:35
Subject: Re: quoting psql varible as identifier

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