I have added the following TODO item on protocol changes:
* Wire Protocol Changes
o Show transaction status in psql
o Allow binding of query parameters, support for prepared queries
o Add optional textual message to NOTIFY
o Remove hard-coded limits on
Hi all,
Mike Mascari [EMAIL PROTECTED] wrote:
Is there any thought about changing the protocol to support
two-phase commit? Not that 2PC and distributed transactions
would be implemented in 7.4, but to prevent another protocol
change in the future?
I'm now implementing 2PC replication and
On Wed, Nov 06, 2002 at 05:02:14PM +0900, Satoshi Nagayasu wrote:
Hannu Krosing [EMAIL PROTECTED] 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
There has been some previous discussion of changing the FE/BE protocol
in 7.4, in order to fix several problems. I think this is worth doing:
if we can resolve all these issues in a single release, it will lessen
the upgrade difficulties for users.
Here are a couple of other changes you might
b) Send a decoded version of atttypmod - specifically, decode the
precision and scale for numeric types.
I want decode type,length,precision and scale
regards
Haris Peco
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
b) Send a decoded version of atttypmod - specifically, decode the
precision and scale for numeric types.
I want decode type,length,precision and scale
Type is returned by PQftype(), length is returned by PQfsize(). Precision
and scale are encoded in the return value from PQfmod() and you
On Thursday 07 November 2002 09:50 pm, korry wrote:
b) Send a decoded version of atttypmod - specifically, decode the
precision and scale for numeric types.
I want decode type,length,precision and scale
Type is returned by PQftype(), length is returned by PQfsize(). Precision
and
Is exists patch for 7.4devel ?
regards
Haris Peco
On Tuesday 05 November 2002 01:14 am, Satoshi Nagayasu wrote:
Hi all,
Mike Mascari [EMAIL PROTECTED] wrote:
Is there any thought about changing the protocol to support
two-phase commit? Not that 2PC and distributed transactions
would be
Hannu Krosing [EMAIL PROTECTED] 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.
Ross J. Reedstrom [EMAIL PROTECTED] wrote:
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
On Mon, Nov 04, 2002 at 07:22:54PM -0500, Neil Conway wrote:
(1) Add an optional textual message to NOTIFY
(2) Remove the hard-coded limits on database and user names
(SM_USER, SM_DATABASE), replace them with variable-length
fields.
(3)
On 11/05/2002 04:42:55 AM Neil Conway wrote:
Mike Mascari [EMAIL PROTECTED] writes:
Is there any thought about changing the protocol to support
two-phase commit? Not that 2PC and distributed transactions would be
implemented in 7.4, but to prevent another protocol change in the
future?
Satoshi Nagayasu kirjutas T, 05.11.2002 kell 08:05:
Tom Lane wrote:
I don't see why 2PC would require any protocol-level change. I would
think that the API would be something like
BEGIN;
issue some commands ...
PRECOMMIT;
-- if the above does not return an error,
Hannu Krosing [EMAIL PROTECTED] wrote:
I think a precommit-vote-commit phase of 2PC can be implemented in
command-lavel or protocol-level.
In command-level 2PC, an user application (or application programmer)
must know the DBMS is clustered or not (to use PRECOMMIT command).
In
On Tue, Nov 05, 2002 at 08:54:46PM +0900, Satoshi Nagayasu wrote:
Hannu Krosing [EMAIL PROTECTED] 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
Neil Conway wrote:
(6) Protocol-level support for prepared queries, in order to
bypass the parser (and maybe be more compatible with the
implementation of prepared queries in other databases).
Let me add
(6b) Protocol level support for query parameters. This
Christof Petig wrote:
Neil Conway wrote:
(6) Protocol-level support for prepared queries, in order to
bypass the parser (and maybe be more compatible with the
implementation of prepared queries in other databases).
Let me add
(6b)Protocol level support
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
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
On Mon, Nov 04, 2002 at 08:10:29PM -0500, Mike Mascari wrote:
Actually, I was thinking along the lines of a true CREATE
DATABASE LINK implementation, where multiple databases could
participate in a distributed transaction. That would require the
backend in which the main query is
I'm now implementing 2PC replication and distributed transaction. My 2PC
needs some supports in startup packet to establish a replication session
or a recovery session.
BTW, my 2PC replication is working, and I'm implementing 2PC recovery now.
I would like to here more about your
Darren Johnson [EMAIL PROTECTED] wrote:
I would like to here more about your implementation. Do you have some
documentation that I
could read?
Documentation is not available, but I have some slides for my presentation.
http://snaga.org/pgsql/20021018_2pc.pdf
Some answers for your
I don't see why 2PC would require any protocol-level change. I would
think that the API would be something like
BEGIN;
issue some commands ...
PRECOMMIT;
-- if the above does not return an error, then
COMMIT;
In other words, 2PC would require some new
Questions have arisen during discussions about errors relating
to how to support error codes without changing the FE/BE
protocols. (see TODO.detail/error)
Now that the protocol is up for revision, how about supporting
sql state strings, error codes, and other information directly in
the protocol.
Grant Finnemore [EMAIL PROTECTED] writes:
Now that the protocol is up for revision, how about supporting
sql state strings, error codes, and other information directly in
the protocol.
Ah, thanks for pointing that out. Error codes would be another thing
we can ideally support in 7.4, and we'd
Tom Lane wrote:
I don't see why 2PC would require any protocol-level change. I would
think that the API would be something like
BEGIN;
issue some commands ...
PRECOMMIT;
-- if the above does not return an error, then
COMMIT;
In other words, 2PC would
Neil Conway wrote:
There has been some previous discussion of changing the FE/BE protocol
in 7.4, in order to fix several problems. I think this is worth doing:
if we can resolve all these issues in a single release, it will lessen
the upgrade difficulties for users.
snip
If I've missed
Mike Mascari [EMAIL PROTECTED] writes:
Is there any thought about changing the protocol to support
two-phase commit? Not that 2PC and distributed transactions would be
implemented in 7.4, but to prevent another protocol change in the
future?
My understanding is that 2PC is one way to
Neil Conway wrote:
Mike Mascari [EMAIL PROTECTED] writes:
Is there any thought about changing the protocol to support
two-phase commit? Not that 2PC and distributed transactions would be
implemented in 7.4, but to prevent another protocol change in the
future?
My understanding is that 2PC is
Hi,
Mike Mascari [EMAIL PROTECTED] wrote:
Is there any thought about changing the protocol to support
two-phase commit? Not that 2PC and distributed transactions
would be implemented in 7.4, but to prevent another protocol
change in the future?
I'm now implementing 2PC replication and
30 matches
Mail list logo
