Satoshi Nagayasu kirjutas K, 06.11.2002 kell 04:15: > > > "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.
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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
