Re: protocol change in 7.4

On Wed, Nov 06, 2002 at 05:02:14PM +0900, Satoshi Nagayasu wrote:
> Hannu Krosing <hannu(at)tm(dot)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. :-)

<snip>

> 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.

So, your replication is an all-or-nothing type of thing? you can't
replicate some tables and not others? If only some tables are replicated,
then you can't decide if this is a distributed transaction until it's
been parsed.

Also, if we want to cascade, then one server can be both master and slave,
as it were. For full-on-2PC, I'm not sure cascading is a good idea, but
it's something to consider, especially if there's provisions for partial
replication, or 'optional' slaves.

>
> 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 Hannu is suggesting that COMMIT could occur from either of two
states in the transaction state diagram: from an open transaction, or
from PRECOMMIT. There's no need to determine before that moment if
this particular transaction is part of a 2PC or not, is there? So, no
you don't _require_ PRECOMMIT/COMMIT because it's clustered: if a
'bare' COMMIT shows up, do what you currently do: hide the details.
If a PRECOMMIT shows up, report status back to the 'client'.

So, it seems to me that the minimum protocol change necessary to support
this model is reporting the current transaction status to the client.

> I think it will confuse the application programmer.

I think your mental image of an application programmer needsto be
expanded: it should also include middleware vendors, who very much want
to be able to control a distributed transaction, one part of which may
be a postgresql replicated cluster.

Ross