"Ross J. Reedstrom" <[EMAIL PROTECTED]> 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. > > > 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. See 10 page. http://snaga.org/pgsql/20021018_2pc.pdf I embeded 'the connection type' in the startup packet to switch postgres backend's behavior (normal FE/BE protocol or 2PC FE/BE protocol). In current implementation, if the connection type is 'R', it is handled as the 2PC FE/BE connection (replication connection). > Does your implementation cascade? Can slaves have slaves? It is not implemented, but I hope so. :-) And I think it is not so difficult. -- NAGAYASU Satoshi <[EMAIL PROTECTED]> ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
