| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Cascading replication and recovery_target_timeline='latest' |
| Date: | 2012-09-04 22:44:31 |
| Message-ID: | 5046844F.6000800@iki.fi |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 04.09.2012 03:02, Dimitri Fontaine wrote:
> Heikki Linnakangas<hlinnaka(at)iki(dot)fi> writes:
>> Hmm, I was thinking that when walsender gets the position it can send the
>> WAL up to, in GetStandbyFlushRecPtr(), it could atomically check the current
>> recovery timeline. If it has changed, refuse to send the new WAL and
>> terminate. That would be a fairly small change, it would just close the
>> window between requesting walsenders to terminate and them actually
>> terminating.
>
> It looks to me like a bug fix that also applies to non cascading
> situation. Is that right?
No, only cascading replication is affected. In non-cascading situation,
the timeline never changes in the master. It's only in cascading mode
that you have a problem, where the standby can cross timelines while
it's replaying the WAL, and also sending it over to cascading standby.
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2012-09-04 23:01:47 | Re: Cascading replication and recovery_target_timeline='latest' |
| Previous Message | Josh Berkus | 2012-09-04 22:41:03 | Re: Cascading replication and recovery_target_timeline='latest' |