Skip site navigation (1) Skip section navigation (2)

Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: "Simon Riggs" <simon(at)2ndQuadrant(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Date: 2011-03-07 14:55:11
Message-ID: 4D749D6F020000250003B55C@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
 
> if you pull the power plug, the transaction that was just being
> committed might be committed on the master, but not yet on the
> standby.
 
> For me, that's enough to call it "synchronous replication". It
> provides useful guarantee to the client.
 
I don't think most people would expect full 2PC behavior from
something called "synchronous replication" -- I agree that a
guarantee that a successful commit means it has been written to the
master and at least one replica is sufficient.
 
> you could argue for an even stricter definition, requiring
> atomicity so that if a transaction is not successfully replicated
> for any reason, including crash, it is rolled back in the master
> too. That would require 2PC.
 
I'm not sure you can say it breaks atomicity; if proper procedures
are followed on recovery, all servers will either reflect the
transaction or not, right?  It seems to me what you lose is the
ability to know whether a transaction for which commit was requested
and for which there had not yet been a reply at the time of failure
is going to be in your recovered database.  In this particular
regard it is no different from a standalone or async replication,
and you would need 2PC with a proper transaction manager to do
better.
 
Getting that additional guarantee may not be worth the performance
hit for most people.  We train our users to save (or make) a paper
copy of whet they were entering if a crash occurs (which, of course,
is very rare, but does happen), so they can check the state of it on
recovery.  It is, of course, important for the programmers to use
appropriate database transaction boundaries so that the database is
always in a state with internal integrity and from which users can
determine the state and proceed on their own.
 
I think we should document the issues, of course.
 
If there is really a demand for a stricter "sync rep" feature, I
think it must be built on top of 2PC and some particular transaction
manager, which seems a though that makes it pgfoundry material.
 
-Kevin

In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2011-03-07 15:03:10
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous:From: Aidan Van DykDate: 2011-03-07 14:29:04
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

pgsql-committers by date

Next:From: Andrew DunstanDate: 2011-03-07 15:03:10
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Previous:From: Aidan Van DykDate: 2011-03-07 14:29:04
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group