Re: Streaming replication, and walsender during recovery - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Streaming replication, and walsender during recovery
Date
Msg-id 3f0b79eb1001280222p423433d0g2f19b9e902c62b37@mail.gmail.com
Whole thread Raw
In response to Re: Streaming replication, and walsender during recovery  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Streaming replication, and walsender during recovery  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Thu, Jan 28, 2010 at 4:47 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.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?

Regards,

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


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: quoting psql varible as identifier
Next
From: Heikki Linnakangas
Date:
Subject: Re: Streaming replication, and walsender during recovery