tab completion for prepared transactions?
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.
Peter Eisentraut <peter_e@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 nontrivial to type.
Hmm, what's the use scenario? I would think that painfully long
gxids would come from some XA manager software, which would be
responsible for committing or canceling them. Manual override
of that would usually be a bad idea.
In short, there's probably no "designed-in reason", but it's not
clear to me that it's worth the code & maintenance effort to have
tab completion for that.
regards, tom lane
On lör, 2010-01-23 at 12:42 -0500, Tom Lane wrote:
Peter Eisentraut <peter_e@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 nontrivial to type.Hmm, what's the use scenario? I would think that painfully long
gxids would come from some XA manager software, which would be
responsible for committing or canceling them. Manual override
of that would usually be a bad idea.
The scenario that I encountered is that you go around manually cleaning
them up when the XA software fails for some reason.
Peter Eisentraut wrote:
On lör, 2010-01-23 at 12:42 -0500, Tom Lane wrote:
Peter Eisentraut <peter_e@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 nontrivial to type.Hmm, what's the use scenario? I would think that painfully long
gxids would come from some XA manager software, which would be
responsible for committing or canceling them. Manual override
of that would usually be a bad idea.
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.
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 for ROLLBACK/COMMIT PREPARED, but not for PREPARE TRANSACTION?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas wrote:
Peter Eisentraut wrote:
On l?r, 2010-01-23 at 12:42 -0500, Tom Lane wrote:
Peter Eisentraut <peter_e@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 nontrivial to type.Hmm, what's the use scenario? I would think that painfully long
gxids would come from some XA manager software, which would be
responsible for committing or canceling them. Manual override
of that would usually be a bad idea.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 think we should add a C comment documenting that fact.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
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 think we should add a C comment documenting that fact.
Hmm, I thought we explained that in the manual, but I can't see it. I
think we should add a note to the ref page of PREPARE TRANSACTION,
something like:
"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 resources. Unless you're writing a transaction
manager, you probably shouldn't be using PREPARE TRANSACTION"
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
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
application server's business.I think we should add a C comment documenting that fact.
Hmm, I thought we explained that in the manual, but I can't see it. I
think we should add a note to the ref page of PREPARE TRANSACTION,
something like:"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 resources. Unless you're writing a transaction
manager, you probably shouldn't be using PREPARE TRANSACTION"
I was thinking of adding something in the psql C source code to explain
why certain commands are not implemented for tab completion.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
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 <peter_e@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 nontrivial to type.Hmm, what's the use scenario? I would think that painfully long
gxids would come from some XA manager software, which would be
responsible for committing or canceling them. Manual override
of that would usually be a bad idea.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.
Maybe so, but that doesn't actually stop people doing it.
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.
--
Simon Riggs www.2ndQuadrant.com
Heikki Linnakangas <heikki.linnakangas@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 for ROLLBACK/COMMIT PREPARED, but not for PREPARE TRANSACTION?
Huh? PREPARE TRANSACTION creates a new gxid, so there's nothing for it
to complete against.
regards, tom lane
Simon Riggs <simon@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 sense at all.
regards, tom lane
On Sun, 2010-01-24 at 12:54 -0500, Tom Lane wrote:
Simon Riggs <simon@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 sense at all.
Agreed
--
Simon Riggs www.2ndQuadrant.com
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 resources. Unless you're writing a transaction
manager, you probably shouldn't be using PREPARE TRANSACTION"
I have never had a chance to use one of these "transaction managers".
I'm probably using it in a non-orthodox way then. What is the
difference between a transaction manager and an application that opens
multiple connections and does PREPARE + COMMIT PREPARED across them?
Tom Lane wrote:
Heikki Linnakangas <heikki.linnakangas@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 it
to complete against.
Well, you could still complete "PREPARE TR" to "PREPARE TRANSACTION",
but I agree it's not very useful. But I was arguing for not having
tab-completion for PREPARE TRANSACTION, so the point is moot anyway.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
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 will know to reconnect to all
the resource managers (ie. databases), check its own transaction log,
decide which global transaction have committed, and issue the
COMMIT/ROLLBACK PREPARED commands to the resource managers to finish the
global transactions.
Sure, you can do all that in an application too, but I have yet to see
one that does (correctly). At the point that you do, you can say that
your application has a built-in transaction manager. Really, if you know
what you're doing, you'll know that note in the manual doesn't apply to you.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
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 transaction. That's
application server's business.I think we should add a C comment documenting that fact.
Hmm, I thought we explained that in the manual, but I can't see it. I
think we should add a note to the ref page of PREPARE TRANSACTION,
something like:"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 resources. Unless you're writing a transaction
manager, you probably shouldn't be using PREPARE TRANSACTION"I was thinking of adding something in the psql C source code to explain
why certain commands are not implemented for tab completion.
Yeah, that's a good idea too.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
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 transactional resources. Unless you're writing a transaction
manager, you probably shouldn't be using PREPARE TRANSACTION"I was thinking of adding something in the psql C source code to explain
why certain commands are not implemented for tab completion.Yeah, that's a good idea too.
Should we remove the completion of COMMIT|ROLLBACK -> PREPARED then?
That's what initially threw me off.