| From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
|---|---|
| To: | robertmhaas(at)gmail(dot)com |
| Cc: | pgsql(at)j-davis(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, markus(at)bluegap(dot)ch, simon(at)2ndquadrant(dot)com, masao(dot)fujii(at)gmail(dot)com, aidan(at)highrise(dot)ca, heikki(dot)linnakangas(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Sync Rep: First Thoughts on Code |
| Date: | 2008-12-14 04:31:12 |
| Message-ID: | 20081214.133112.10915603.t-ishii@sraoss.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> The point here is that synchronous replication, at least to some
> people, is going to imply that the user-visible states of the two
> copies are consistent. To other people, it is going to imply that
> committed transactions will never be lost even in the event of a
> catastropic loss of the primary 1 picosecond after the commit is
> acknowledged. We need to choose some word that implies that we are
> guaranteeing the latter of these two things but not the former.
> Otherwise, we will have confused users, and terminological confusion
> when and if we ever implement the former as well.
Right. Before watching this thread, I had thought that the log
shipping sync replication behaves former (and I had told so to people
in Japan who are interested in 8.4 development. Of course this is my
fault, though).
Now I understand the log shipping sync replication does not behave
same as other "sync replications" such as pgpool and PGCluster (there
maybe more, but I don't know)
--
Tatsuo Ishii
SRA OSS, Inc. Japan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2008-12-14 05:42:12 | Re: Sync Rep: First Thoughts on Code |
| Previous Message | Robert Haas | 2008-12-14 03:34:37 | Re: WIP: default values for function parameters |