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 user/db/pa
On Friday 08 November 2002 09:29 am, Hannu Krosing wrote:
> snpe kirjutas R, 08.11.2002 kell 03:49:
> > > PQfsize() is entertaining, but not often what you really want (you
> > > really want the width of the widest value in the column after
> > > conversion to some string format - it seems reason
snpe kirjutas R, 08.11.2002 kell 03:49:
> > PQfsize() is entertaining, but not often what you really want (you really
> > want the width of the widest value in the column after conversion to some
> > string format - it seems reasonable to let the client applicatin worry
> > about that, although m
> Is exists patch for 7.4devel ?
A full tarball is based on 7.3devel.
There is no patch for 7.4devel.
http://snaga.org/pgsql/
--
NAGAYASU Satoshi <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
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(). Precisi
> 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 y
> 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
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 c
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
> >
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 fro
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 replicatio
"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 i
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 pr
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 fo
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 wou
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.
"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 anywa
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 witho
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)
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 retu
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
>
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
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 w
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 w
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.
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 comm
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 que
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 implementati
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 an
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 execu
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
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 imp
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.
If I've missed anything
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.
I'm aware of the following problems that need a p
34 matches
Mail list logo
