Hi,
Mark Mielke wrote:
> Robert Haas wrote:
>> On Sat, Dec 13, 2008 at 1:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> We won't call it anything, because we never will or can implement that.
>>> See the theory of relativity: the notion of exactly simultaneous events
>>
>> OK, fine. I'll be more precise. I think we need to reserve the term
>> "synchronous replication" for a system where transactions that begin
>> on the standby after the transactions has committed on the master see
>> the effects of the committed transaction.
I agree with Robert here. As far as I know this is the common
understanding of "synchronous replication". Everything less - including
Postgres-R - is considered to be asynchronous.
> I'd like to see proof of some sort that PostgreSQL guarantees that the
> instant a 'commit' returns, any transactions already open with the
> appropriate transaction isolation level, or any new sessions *will* see
> the results of the commit.
Given within this thread, here [1].
> Two phase commit doesn't imply that the transaction is guaranteed to be
> immediately visible.
Just for the record: that's plain wrong. As with any other transaction,
a COMMIT of a prepared transaction guarantees visibility from all
subsequent snapshots (at least for Postgres and other serious RDBSen).
Systems based on 2PC are the typical synchronous replication solution:
works, resistant to failures, consistent across nodes (WRT visibility),
but unusably slow. This is what people have in mind and expect when they
hear "synchronous replication" for databases. (And which is why I'm
thinking it's better for an optimized solution not to call itself
"synchronous").
> Unless transactions are
> locked from starting until they are able to prove that they have the
> latest commit
See the cited README. It already happens for (single node) Postgres
systems, because the action of snapshot taking and committing are
serialized.
> (a feat which I'm going to theorize as impossible -
> because the moment you wait for a commit, and you begin again, you
> really have no guarantee that another commit has not occurred in the
> mean time)
This problem is solved by locking.
Regards
Markus Wanner
[1]: Hints to docs and source, that COMMIT actually ensures subsequent
snapshots "include" changes of the committed transaction:
http://archives.postgresql.org/message-id/494CFFFF.2060200@bluegap.ch
