From: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sync Rep: First Thoughts on Code |
Date: | 2008-12-10 20:06:47 |
Message-ID: | 20081210200647.GS26596@yugib.highrise.ca |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Simon Riggs <simon(at)2ndQuadrant(dot)com> [081210 14:58]:
> I think you just went down the same path I did before. (That's a good
> sign).
>
> When the WAL starts streaming the *primary* can immediately perform
> synchronous replication, i.e. commit waits for transfer. The *standby*
> has an initial lag before it catches up, whatever we do (as you say).
>
> I suggested that way initially because it simplifies the mode change.
> The mode change isn't really that complex, so I agreed we should change
> it.
>
> The two ways of doing this are/were:
>
> 1. (Initial suggestion)
> * allow standby to catchup
> * then connect and allow sync rep
>
> 2. Preferred Choice
> * connect to primary and allow sync rep
> * catch up
Call me think, but I'm confused... In sync rep, there *can't be* any
catchign up do do... i.e. if the "slave" isn't accepting the WAL the
master "stops" doing *anything*...
--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-12-10 20:11:59 | Re: Sync Rep: First Thoughts on Code |
Previous Message | Simon Riggs | 2008-12-10 20:04:17 | Re: Sync Rep: First Thoughts on Code |