Remember how we make SET/SHOW/RESET _not_ be part of a multi-statement
transaction when it is at the start of a transaction and autocommit is
off?

Well, look at this:
	
	test=> SET random_page_cost = 2;
	SET
	test=> COMMIT;
	WARNING:  COMMIT: no transaction in progress
	COMMIT

The WARNING happens with SHOW and RESET too.  I wonder if we should
suppress the WARNING of a COMMIT with no statements when autocommit is
off.  This will probably be better for portability, though again, it is
confusing.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Sat, 19 Oct 2002 22:56:49 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
New SET/autocommit problem
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> 	WARNING:  COMMIT: no transaction in progress
> 	COMMIT

> The WARNING happens with SHOW and RESET too.  I wonder if we should
> suppress the WARNING of a COMMIT with no statements when autocommit is
> off.

I don't think so; that will make it quite hard to check whether a
transaction is open.

			regards, tom lane

Sat, 19 Oct 2002 23:49:46 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: New SET/autocommit problem 
> > 	WARNING:  COMMIT: no transaction in progress
> > 	COMMIT
> 
> > The WARNING happens with SHOW and RESET too.  I wonder if we should
> > suppress the WARNING of a COMMIT with no statements when autocommit is
> > off.
> 
> I don't think so; that will make it quite hard to check whether a
> transaction is open.

I've got tons of these warnings in my logs... is there a programmatic
way of determining if the current session is in a transaction?  Unless
I misunderstood the fix and the commit message, I'm pretty sure that
most of my problem has been fixed in CVS with SET's auto-committing if
it's not in a transaction, but now that there are some intricate rules
with regards to starting transactions, I'd love to provide a DBI
interface into a call that returns whether or not we're in a
transaction to prevent millions of these:

NOTICE:  ROLLBACK: no transaction in progress

-sc

-- 
Sean Chittenden

Tue, 22 Oct 2002 00:12:41 -0700
Sean Chittenden <sean@chittenden.org>
Re: New SET/autocommit problem
Sean Chittenden <sean@chittenden.org> writes:
> WARNING:  COMMIT: no transaction in progress

> I've got tons of these warnings in my logs... is there a programmatic
> way of determining if the current session is in a transaction?

Not at present: you have to track it for yourself.  One of the
suggestions on the list for the next frontend/backend protocol revision
(probably in 7.4) is to add a way for the backend to signal its
transaction state: no transaction, in transaction, or in failed
transaction seems like the set of possible states.

			regards, tom lane

Tue, 22 Oct 2002 09:24:30 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: New SET/autocommit problem 
> > WARNING:  COMMIT: no transaction in progress
> 
> > I've got tons of these warnings in my logs... is there a programmatic
> > way of determining if the current session is in a transaction?
> 
> Not at present: you have to track it for yourself.  One of the
> suggestions on the list for the next frontend/backend protocol revision
> (probably in 7.4) is to add a way for the backend to signal its
> transaction state: no transaction, in transaction, or in failed
> transaction seems like the set of possible states.

That would be fabulous because with autocommit set to off, the
complexity for tracking that in application is getting pretty
gnarly. -sc

-- 
Sean Chittenden

Tue, 22 Oct 2002 10:10:46 -0700
Sean Chittenden <sean@chittenden.org>
Re: New SET/autocommit problem