Re: protocol change in 7.4
От | Ross J. Reedstrom |
---|---|
Тема | Re: protocol change in 7.4 |
Дата | |
Msg-id | 20021105160653.GA13860@wallace.ece.rice.edu обсуждение исходный текст |
Ответ на | Re: protocol change in 7.4 (Satoshi Nagayasu <pgsql@snaga.org>) |
Ответы |
Re: protocol change in 7.4
|
Список | pgsql-hackers |
On Tue, Nov 05, 2002 at 08:54:46PM +0900, Satoshi Nagayasu wrote: > > > Hannu Krosing <hannu@tm.ee> wrote: > > > > > > 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 ? 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. > 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. Does your implementation cascade? Can slaves have slaves? Ross
В списке pgsql-hackers по дате отправления: