Re: A bad behavior under autocommit off mode

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A bad behavior under autocommit off mode
Date: 2003-03-19 17:18:39
Message-ID: 200303191718.h2JHIdV25808@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


OK, I have a patch to fix this bug. The basic problem is that when a
multi-query string is passed to the backend, it is treated as a single
transaction _unless_ a transaction or GUC command appears in the string.
When they appear, a transaction is forced, but the normal transaction
state machine has been bypassed, meaning in:

SET autocommit TO off; SELECT 1; COMMIT;

when the COMMIT arrives, the transaction state machines hasn't seen the
SELECT because the mechanism is bypassing the state machine to try and
get everything into the same transaction.

This patch removes that "stuff all queries into a single transaction"
behavior and makes them function just like queries arriving separately.
This does BREAK BACKWARD COMPATIBILITY. However, if they want the old
behavior, they just need to wrap BEGIN/COMMIT around the query string.

I could have fixed it with a hack to the transaction state machine, but
this seems like the proper fix. I never liked that single-transaction
query string behavior anyway. It seemed too strange.

---------------------------------------------------------------------------

Hiroshi Inoue wrote:
> Hi all,
>
> There seems a bad behavior under autocommit off mode.
>
> 1) psql -c 'set autocommit to off;select 1;commit'
> causes a WARNING: COMMIT: no transaction in progress
> whereas
> 2) psql -c 'begin;select 1;commit'
> causes no error/warning.
>
> Note that the result is the same even when you issue
> the first set/begin command separately using the client
> softwares other than psql.
>
> The problem here is that the transaction is cancelled
> in case of 1) though no error is reported.
> Shouldn't we avoid the warning and the cancellation ?
> Or should an error be reported instead of the warning ?
>
> regards,
> Hiroshi Inoue
> http://www.geocities.jp/inocchichichi/psqlodbc/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

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

Attachment Content-Type Size
unknown_filename text/plain 1.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2003-03-19 17:20:20 Re: PostgreSQL flamage on Slashdot
Previous Message Tom Lane 2003-03-19 16:18:38 Re: Nested transactions: low level stuff