Thread: Small question
Hi, Is there a way to determine whether a transaction is started and not ended yet? I.e. is it possible to check whether a "begin"was issued but the corresponding "commit/end" wasn't yet? I'm using the c++ interface for Postgres7.1. (But I hope the answer is independent of that) Many thanx in advance, Joep.
Joep deVocht wrote:
>
> Hi,
>
> Is there a way to determine whether a transaction
> is started and not ended yet? I.e. is it possible to
> check whether a "begin"was issued but the corresponding
> "commit/end" wasn't yet?
>
> I'm using the c++ interface for Postgres7.1.
> (But I hope the answer is independent of that)
>
> Many thanx in advance,
This question came from time to time, and many interfaces
seem to try to keep track of the actual transaction status in
order to emulate autocommit off behaviour and such.
The only one who's really able to tell the current
transaction state is the backend.
I think it's time to add a little boolean function, that
actually returns IsTransactionBlock(), and have a libpq side
wrapper around PQfn() calling it.
Any other opinions?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Jan Wieck <janwieck@yahoo.com> writes:
> Joep deVocht wrote:
>> Is there a way to determine whether a transaction
>> is started and not ended yet?
> I think it's time to add a little boolean function, that
> actually returns IsTransactionBlock(), and have a libpq side
> wrapper around PQfn() calling it.
If you're in TRANSACTION ABORT state, I do not think that will work.
Offhand this seems more of a protocol issue. A straightforward solution
would be to add a status indicator (with three states: out of
transaction, in transaction, in aborted transaction) to the
ReadyForQuery message, but we can't do that without a protocol change,
which is probably more trouble than it's worth.
It seems like it might be possible for libpq (or other clients) to keep
track of the transaction state by paying attention to BEGIN, COMMIT,
ABORT command-completion tags and ERROR messages, but I haven't worked
through the details.
regards, tom lane
Tom Lane wrote: > Jan Wieck <janwieck@yahoo.com> writes: > > Joep deVocht wrote: > >> Is there a way to determine whether a transaction > >> is started and not ended yet? > > > I think it's time to add a little boolean function, that > > actually returns IsTransactionBlock(), and have a libpq side > > wrapper around PQfn() calling it. > > If you're in TRANSACTION ABORT state, I do not think that will work. > > Offhand this seems more of a protocol issue. A straightforward solution > would be to add a status indicator (with three states: out of > transaction, in transaction, in aborted transaction) to the > ReadyForQuery message, but we can't do that without a protocol change, > which is probably more trouble than it's worth. Yes, I was wondering if it was worth having the client call the function at the end of every query. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian wrote:
> Tom Lane wrote:
> > Jan Wieck <janwieck@yahoo.com> writes:
> > > Joep deVocht wrote:
> > >> Is there a way to determine whether a transaction
> > >> is started and not ended yet?
> >
> > > I think it's time to add a little boolean function, that
> > > actually returns IsTransactionBlock(), and have a libpq side
> > > wrapper around PQfn() calling it.
> >
> > If you're in TRANSACTION ABORT state, I do not think that will work.
> >
> > Offhand this seems more of a protocol issue. A straightforward solution
> > would be to add a status indicator (with three states: out of
> > transaction, in transaction, in aborted transaction) to the
> > ReadyForQuery message, but we can't do that without a protocol change,
> > which is probably more trouble than it's worth.
>
> Yes, I was wondering if it was worth having the client call the function
> at the end of every query.
Who said that it'll be called after every query? It will
only be called when the application asks for the current
state. Sort of client side
bool PQisTransactionBlock(PGconn *conn);
I don't really see how that functionality could be a problem.
I agree with Tom so far, that it has to be in the FE/BE
protocol. It just seems none of us likes protocol changes.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Tom Lane wrote:
> Jan Wieck <janwieck@yahoo.com> writes:
> > Joep deVocht wrote:
> >> Is there a way to determine whether a transaction
> >> is started and not ended yet?
>
> > I think it's time to add a little boolean function, that
> > actually returns IsTransactionBlock(), and have a libpq side
> > wrapper around PQfn() calling it.
>
> If you're in TRANSACTION ABORT state, I do not think that will work.
Sort of, because that's the only moment when PQfn() will
result in something different than PGRES_COMMAND_OK :-)
>
> Offhand this seems more of a protocol issue. A straightforward solution
> would be to add a status indicator (with three states: out of
> transaction, in transaction, in aborted transaction) to the
> ReadyForQuery message, but we can't do that without a protocol change,
> which is probably more trouble than it's worth.
>
> It seems like it might be possible for libpq (or other clients) to keep
> track of the transaction state by paying attention to BEGIN, COMMIT,
> ABORT command-completion tags and ERROR messages, but I haven't worked
> through the details.
PQexec(c, "BEGIN; SELECT now()");
Will there even be a BEGIN command tag sent?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Jan Wieck wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > > > Jan Wieck <janwieck@yahoo.com> writes: > > > > Joep deVocht wrote: > > > >> Is there a way to determine whether a transaction > > > >> is started and not ended yet? > > > > > > > I think it's time to add a little boolean function, that > > > > actually returns IsTransactionBlock(), and have a libpq side > > > > wrapper around PQfn() calling it. > > > > > > If you're in TRANSACTION ABORT state, I do not think that will work. > > > > > > Offhand this seems more of a protocol issue. A straightforward solution > > > would be to add a status indicator (with three states: out of > > > transaction, in transaction, in aborted transaction) to the > > > ReadyForQuery message, but we can't do that without a protocol change, > > > which is probably more trouble than it's worth. > > > > Yes, I was wondering if it was worth having the client call the function > > at the end of every query. > > Who said that it'll be called after every query? It will > only be called when the application asks for the current > state. Sort of client side > > bool PQisTransactionBlock(PGconn *conn); > > I don't really see how that functionality could be a problem. I just thought that most applications that need to know the state need to know for almost every new query. We had the request to update the psql prompt with transaction status, and clearly the call would be needed frequently. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Jan Wieck <janwieck@yahoo.com> writes:
>> It seems like it might be possible for libpq (or other clients) to keep
>> track of the transaction state by paying attention to BEGIN, COMMIT,
>> ABORT command-completion tags and ERROR messages, but I haven't worked
>> through the details.
> PQexec(c, "BEGIN; SELECT now()");
> Will there even be a BEGIN command tag sent?
Yes. PQexec doesn't tell you about it, but one comes through. (This
is certainly true in current sources, and I believe has always been true.)
It'd be nastier if we allowed functions to change the transaction-block
state, but we don't...
regards, tom lane
Tom Lane wrote: > Jan Wieck <janwieck@yahoo.com> writes: > >> It seems like it might be possible for libpq (or other clients) to keep > >> track of the transaction state by paying attention to BEGIN, COMMIT, > >> ABORT command-completion tags and ERROR messages, but I haven't worked > >> through the details. > > > PQexec(c, "BEGIN; SELECT now()"); > > > Will there even be a BEGIN command tag sent? > > Yes. PQexec doesn't tell you about it, but one comes through. (This > is certainly true in current sources, and I believe has always been true.) > > It'd be nastier if we allowed functions to change the transaction-block > state, but we don't... We only need one bit to pass the transaction status back to the client. Shame we can't throw that bit in there somewhere. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Tom Lane wrote:
> Jan Wieck <janwieck@yahoo.com> writes:
> >> It seems like it might be possible for libpq (or other clients) to keep
> >> track of the transaction state by paying attention to BEGIN, COMMIT,
> >> ABORT command-completion tags and ERROR messages, but I haven't worked
> >> through the details.
>
> > PQexec(c, "BEGIN; SELECT now()");
>
> > Will there even be a BEGIN command tag sent?
>
> Yes. PQexec doesn't tell you about it, but one comes through. (This
> is certainly true in current sources, and I believe has always been true.)
>
> It'd be nastier if we allowed functions to change the transaction-block
> state, but we don't...
Well, then we don't need a protocol change. Libpq and other
interface libraries could keep track of it without.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Bruce Momjian wrote:
> Tom Lane wrote:
> > Jan Wieck <janwieck@yahoo.com> writes:
> > >> It seems like it might be possible for libpq (or other clients) to keep
> > >> track of the transaction state by paying attention to BEGIN, COMMIT,
> > >> ABORT command-completion tags and ERROR messages, but I haven't worked
> > >> through the details.
> >
> > > PQexec(c, "BEGIN; SELECT now()");
> >
> > > Will there even be a BEGIN command tag sent?
> >
> > Yes. PQexec doesn't tell you about it, but one comes through. (This
> > is certainly true in current sources, and I believe has always been true.)
> >
> > It'd be nastier if we allowed functions to change the transaction-block
> > state, but we don't...
>
> We only need one bit to pass the transaction status back to the client.
> Shame we can't throw that bit in there somewhere.
Huh? You can represent 3 possible states in one bit? I know
that I'm not too bad of a programmer, but you're far better
than me :-p
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Jan Wieck wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > > > Jan Wieck <janwieck@yahoo.com> writes: > > > >> It seems like it might be possible for libpq (or other clients) to keep > > > >> track of the transaction state by paying attention to BEGIN, COMMIT, > > > >> ABORT command-completion tags and ERROR messages, but I haven't worked > > > >> through the details. > > > > > > > PQexec(c, "BEGIN; SELECT now()"); > > > > > > > Will there even be a BEGIN command tag sent? > > > > > > Yes. PQexec doesn't tell you about it, but one comes through. (This > > > is certainly true in current sources, and I believe has always been true.) > > > > > > It'd be nastier if we allowed functions to change the transaction-block > > > state, but we don't... > > > > We only need one bit to pass the transaction status back to the client. > > Shame we can't throw that bit in there somewhere. > > Huh? You can represent 3 possible states in one bit? I know > that I'm not too bad of a programmer, but you're far better > than me :-p > Compression, of course. ;-) -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026