Re: protocol change in 7.4 - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: protocol change in 7.4
Date
Msg-id 1036486038.17175.3.camel@taru.tm.ee
Whole thread Raw
In response to Re: protocol change in 7.4  (Satoshi Nagayasu <pgsql@snaga.org>)
Responses Re: protocol change in 7.4  (Satoshi Nagayasu <pgsql@snaga.org>)
List 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



pgsql-hackers by date:

Previous
From: Maarten Boekhold
Date:
Subject: Re: protocol change in 7.4
Next
From: Peter Eisentraut
Date:
Subject: Re: Is my Internet connection slow