From: Kevin Grittner <Kevin.Grittner@wicourts.gov>
To: Andrew Dunstan <andrew@dunslane.net>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Simon Riggs <simon@2ndQuadrant.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Date: Mon, 07 Mar 2011 08:55:11 -0600
Message-ID: <4D749D6F020000250003B55C@gw.wicourts.gov> (raw)
In-Reply-To: <4D74E584.7080409@enterprisedb.com>
References: <E1PwMns-00047O-UU@gemulon.postgresql.org>
<4D741441.2090704@dunslane.net>
<1299454125.1696.6138.camel@ebony>
<4D74896C.5030402@enterprisedb.com>
<4D74DDFA.70800@dunslane.net>
<4D74E584.7080409@enterprisedb.com>
Heikki Linnakangas <heikki.linnakangas@enterprisedb.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: Kevin.Grittner@wicourts.gov, andrew@dunslane.net, heikki.linnakangas@enterprisedb.com, simon@2ndQuadrant.com, pgsql-hackers@postgresql.org
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
In-Reply-To: <4D749D6F020000250003B55C@gw.wicourts.gov>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox