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

Satoshi Nagayasu kirjutas K, 06.11.2002 kell 04:15:
> 
> 
> "Ross J. Reedstrom" <reedstrm@rice.edu> wrote:
> > > > 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 ?
> > 
> > No, I think Satoshi is suggesting that from the client's point of view,
> > he's embedded the entire precommit-vote-commit cycle inside the COMMIT
> > command.
> 
> Exactly.  When user send the COMMIT command to the master server, the
> master.talks to the slaves to process precommit-vote-commit using the
> 2PC. The 2PC cycle is hidden from user application.  User application
> just talks the normal FE/BE protocol.

But _can_ client (libpq/jdbc/...) also talk 2PC FE/BE protocol, i.e. act
as "master" ?

> > > In my implementation, 'the extended(2PC) FE/BE protocol' is used only in
> > > the communication between the master and slave server(s), not between a
> > > client app and the master server.
> > > 
> > > libpq <--Normal FE/BE--> (master)postgres <--Extended(2PC)FE/BE--> (slave)postgres
> > >                                           <--Extended(2PC)FE/BE--> (slave)postgres
> > >                                           <--Extended(2PC)FE/BE--> (slave)postgres
> > > 
> > > A client application and client's libpq can work continuously without
> > > any modification. This is very important. And protocol modification
> > > between master and slave server(s) is not so serious issue (I think).
> > > 
> > 
> > Ah, but this limits your use of 2PC to transparent DB replication - since
> > the client doesn't have access to the PRECOMMIT phase (usually called
> > prepare phase, but that's anothor overloaded term in the DB world!) it
> > _can't_ serve as the transaction master, so the other use cases that
> > people have mentioned here (zope, MOMs, etc.) wouldn't be possible.
> > 
> > Hmm, unless a connection can be switched into 2PC mode, so something
> > other than a postgresql server can act as the transaction master.
> 
> I think the client should not act as the transaction master.  But if it
> is needed, the client can talk to postgres servers with the extended 2PC
> FE/BE protocol.
> 
> Because all postgres servers(master and slave) can understand both the
> normal FE/BE protocol and the extended 2PC FE/BE protocol. It is
> switched in the startup packet.

Why is the protocol change neccessary ?

Is there some fundamental reason that the slave backends can't just wait
and see if the first "commit" command is PRECOMMIT or COMMIT and then
act accordingly on for each transaction ?

-----------------
Hannu