| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(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 07:47:13 |
| Message-ID: | 4B614101.2080603@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Fujii Masao wrote:
> OK. Here is the patch which supports a walsender process during recovery;
>
> * Change walsender so as to send the WAL written by the walreceiver
> if it has been started during recovery.
> * Kill the walsenders started during recovery at the end of recovery
> because replication cannot survive the change of timeline ID.
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.
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2010-01-28 08:28:26 | Re: Streaming replication and pg_xlogfile_name() |
| Previous Message | Heikki Linnakangas | 2010-01-28 07:31:54 | Re: Streaming replication and wal skipping |