From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql(at)j-davis(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, markus(at)bluegap(dot)ch, 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-15 09:40:43 |
Message-ID: | 1229334043.8673.246.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 2008-12-14 at 21:41 -0500, Robert Haas wrote:
> > If this is right, #2, #3, #4, and #6 feel similar except
> > that they're protecting against failures of different (but
> > still all incomplete) subsets of the hardware on the slave, right?
>
> Right. Actually, the biggest difference with #6 has nothing to do
> with protecting against failures. It has rather to do with the ease
> of writing applications in the context of hot standby. You can close
> your connection, open a connection to a different server, and know
> that your transactions will be reflected there. On the other hand,
> I'd be surprised if it didn't come with a substantial performance
> penalty, so it may not be too practical in real life even if it sounds
> good on paper.
>
> #1 , #3, and #5 don't feel that useful to me.
Yes, looks that way for me also.
Good analysis Ron. I agree with Robert that #6 is there for other
reasons.
#2 corresponds to DRBD algorithm B
#4 corresponds to DRBD algorithm C
Fujii-san, please can we incorporate those two options, rather than just
one choice "synchronous_replication = on". They look like two commonly
requested options.
#6 is an additional synchronization step in Hot Standby. I would say
that people won't want that when they see how it performs (they probably
won't want #4 either for that same reason, but that is for robustness).
Also, I would point out that the class of synch_rep is selected by the
user on the primary and can vary from transaction to transaction. That
is a very good thing, as far as I am concerned. We would need to enforce
#6 for all transactions (if we implemented synchronisation in this way).
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2008-12-15 09:44:25 | Re: Sync Rep: First Thoughts on Code |
Previous Message | Simon Riggs | 2008-12-15 09:38:41 | Re: Sync Rep: First Thoughts on Code |