Re: protocol change in 7.4

"Ross J. Reedstrom" <reedstrm(at)rice(dot)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.

>
> > 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 <snaga(at)snaga(dot)org>