On sön, 2010-01-24 at 21:56 +0200, Heikki Linnakangas wrote:
PREPARE TRANSACTION is not intended for use in applications or in
interactive sessions. It's purpose is to allow an external transaction
manager to perform atomic global transactions across multiple databases
or other
Peter Eisentraut wrote:
On lör, 2010-01-23 at 12:42 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Was there a designed-in reason not to have psql tab completion for
COMMIT/ROLLBACK PREPARED ...? It does complete the PREPARED but not
the transaction identifiers. Maybe it's
Heikki Linnakangas wrote:
Peter Eisentraut wrote:
On l?r, 2010-01-23 at 12:42 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Was there a designed-in reason not to have psql tab completion for
COMMIT/ROLLBACK PREPARED ...? It does complete the PREPARED but not
the
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Right, I vaguely recall that the idea of tab-completion for those
commands was rejected when 2PC was added because of that. A user sitting
at a psql terminal is not supposed to prepare a transaction. That's
application server's business.
I
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Right, I vaguely recall that the idea of tab-completion for those
commands was rejected when 2PC was added because of that. A user sitting
at a psql terminal is not supposed to prepare a transaction. That's
On Sun, 2010-01-24 at 19:29 +0200, Heikki Linnakangas wrote:
Peter Eisentraut wrote:
On lör, 2010-01-23 at 12:42 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Was there a designed-in reason not to have psql tab completion for
COMMIT/ROLLBACK PREPARED ...? It does
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Peter Eisentraut wrote:
The scenario that I encountered is that you go around manually cleaning
them up when the XA software fails for some reason.
Hmm, that's a good point though. Maybe it would make sense to add tab
completion
Simon Riggs si...@2ndquadrant.com writes:
I would like a mechanism in the server to prevent a session from
accepting anything other than COMMIT or ROLLBACK PREPARED after a
PREPARE. Otherwise it's possible to screw up your prepared xact and
leave it hanging there.
Uh, what? That makes no
On Sun, 2010-01-24 at 12:54 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
I would like a mechanism in the server to prevent a session from
accepting anything other than COMMIT or ROLLBACK PREPARED after a
PREPARE. Otherwise it's possible to screw up your prepared xact and
On sön, 2010-01-24 at 19:43 +0200, Heikki Linnakangas wrote:
PREPARE TRANSACTION is not intended for use in applications or in
interactive sessions. It's purpose is to allow an external transaction
manager to perform atomic global transactions across multiple
databases
or other transactional
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, that's a good point though. Maybe it would make sense to add tab
completion for ROLLBACK/COMMIT PREPARED, but not for PREPARE TRANSACTION?
Huh? PREPARE TRANSACTION creates a new gxid, so there's nothing for
Peter Eisentraut wrote:
What is the
difference between a transaction manager and an application that opens
multiple connections and does PREPARE + COMMIT PREPARED across them?
It's what happens if your application crashes after issuing the PREPARE.
A correctly configured transaction manager
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Right, I vaguely recall that the idea of tab-completion for those
commands was rejected when 2PC was added because of that. A user sitting
at a psql terminal is not supposed to prepare a
Was there a designed-in reason not to have psql tab completion for
COMMIT/ROLLBACK PREPARED ...? It does complete the PREPARED but not
the transaction identifiers. Maybe it's not a common use case, but
these transaction identifiers sure can be nontrivial to type.
--
Sent via pgsql-hackers
Peter Eisentraut pete...@gmx.net writes:
Was there a designed-in reason not to have psql tab completion for
COMMIT/ROLLBACK PREPARED ...? It does complete the PREPARED but not
the transaction identifiers. Maybe it's not a common use case, but
these transaction identifiers sure can be
On lör, 2010-01-23 at 12:42 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Was there a designed-in reason not to have psql tab completion for
COMMIT/ROLLBACK PREPARED ...? It does complete the PREPARED but not
the transaction identifiers. Maybe it's not a common use case,
16 matches
Mail list logo
