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