Hannu Krosing <hannu@tm.ee> wrote:
> > 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" ?
Not for now. The current libpq/jdbc can talk only normal FE/BE protocol.
But it can be implemented.
Because my (experimantal)libpq can talk 2PC FE/BE protocol. :-)
> >
> > 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 ?
Because the postgres backend must detect a type of incomming connection
(from the client app or the master).
If it is comming from the client, the backend relays the queries to the
slaves (act as the master).
But if it is comming from the master server, the backend must act as a
slave, and does not relay the queries.
How the backend detect them in the multi-master replication? Detecting
inside the start packet is a simple way.
My implementation is working without protocol modification, because the
session type information is embeded in the 'unused' field now. So the
backend can understand both the normal FE/BE protocol and the extended
2PC FE/BE protocol.
But if the unused field is removed in 7.4, my replication will not work.
I think there are several types of connection in the sync replication or
the distributed transaction. Especially, the bulk transfer of tables or
indexes will be neccesary for the distributed query in future.
So, I think embedding the connection type information in the startup
packet is a good idea.
>
> 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 ?
Are two "commit" commands required on the clustered postgres?
And is one "commit" command required on the single postgres?
I think it will confuse the application programmer.
--
NAGAYASU Satoshi <snaga@snaga.org>
