From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Satoshi Nagayasu <pgsql(at)snaga(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, darren(at)up(dot)hrcoxmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: protocol change in 7.4 |
Date: | 2002-11-05 08:47:18 |
Message-ID: | 1036486038.17175.3.camel@taru.tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Satoshi Nagayasu kirjutas T, 05.11.2002 kell 08:05:
> 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).
If application continues to use just BEGIN/COMMIT, then the protocol
level must parse command stream and recognize COMMIT in order to replace
it with PRECOMMIT, COMMIT.
If the communication library has to do that anyway, it could still do
the replacement without affecting wire protocol, no ?
------------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Luis Alberto Amigo Navarro | 2002-11-05 08:58:50 | a tiny question |
Previous Message | Oleg Bartunov | 2002-11-05 08:41:04 | Re: Another bug in tsearch? |