Re: Implicit transaction not rolling back after error - Mailing list pgsql-general

From Scott Marlowe
Subject Re: Implicit transaction not rolling back after error
Date
Msg-id CAOR=d=0LGmuvnE06Wj1NozcezBzOem_Vshz5xsVhWEuQpLgxVw@mail.gmail.com
Whole thread Raw
In response to Re: Implicit transaction not rolling back after error  (Stephen Touset <stephen.touset@onelogin.com>)
List pgsql-general
On Thu, Dec 20, 2012 at 7:04 PM, Stephen Touset
<stephen.touset@onelogin.com> wrote:
> On Dec 20, 2012, at 3:40 PM, Rob Sargent <robjsargent@gmail.com> wrote:
>
>> On 12/20/2012 04:33 PM, Stephen Touset wrote:
>>
>>> So yes, AUTOCOMMIT is definitely on.
>>
>> What does \set show when entered from the psql command line?
>
>    test=> \set
>    AUTOCOMMIT = 'OFF'
>
> *facepalm*.

\set is a psql command

> Turns out someone put a .psqlrc with autocommit off in /etc/skel when the box was originally set up as a replacement
forour previous app server. Account users were created afterwards, and the change propagated to our application account
aswell as all of our individual accounts. 
>
> Why, though, would `SHOW AUTOCOMMIT` lie? And `SET AUTOCOMMIT TO off` says that capability is disabled. So how does
theconfig file manage to do it? 

show variable is a SQL command to the backend engine.  The backend
does not support autocommit on / off (it did once upon a time for a
little while but it broke lots of stuff and got reverted).

autocommit is now firmly a client side behavior, not a backend behavior.


pgsql-general by date:

Previous
From: Stephen Touset
Date:
Subject: Re: Implicit transaction not rolling back after error
Next
From: Tom Lane
Date:
Subject: Re: Using POSIX Regular Expressions on xml type fields gives inconsistent results