From: | Satoshi Nagayasu <pgsql(at)snaga(dot)org> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql(at)snaga(dot)org, darren(at)up(dot)hrcoxmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: protocol change in 7.4 |
Date: | 2002-11-05 06:05:55 |
Message-ID: | 200211050605.gA565tD17709@penguin.bioinfo.sfc.keio.ac.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> I don't see why 2PC would require any protocol-level change. I would
> think that the API would be something like
>
> BEGIN;
> issue some commands ...
> PRECOMMIT;
> -- if the above does not return an error, then
> COMMIT;
>
> In other words, 2PC would require some new commands, but a new command
> doesn't affect the protocol layer.
I think a precommit-vote-commit phase of 2PC can be implemented in
command-lavel or protocol-level.
In command-level 2PC, an user application (or application programmer)
must know the DBMS is clustered or not (to use PRECOMMIT command).
In protocol-layer 2PC, no new SQL command is required.
A precommit-vote-commit phase will be called implicitly. It means an
user application can be used without any modification. An application
can use a traditional way (BEGIN...COMMIT).
So I made my decision to use protocol-layer implementation.
It doesn't affect the SQL command layer.
--
NAGAYASU Satoshi <snaga(at)snaga(dot)org>
From | Date | Subject | |
---|---|---|---|
Next Message | Roj Niyogi | 2002-11-05 06:11:34 | Re: [HACKERS] PostgreSQL IRC Channel... who's the Admin? |
Previous Message | Neil Conway | 2002-11-05 05:57:24 | Re: [HACKERS] PostgreSQL IRC Channel... who's the Admin? |