Re: protocol change in 7.4

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

In response to

Responses

Browse pgsql-hackers by date

  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?