Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm using PostgreSQL 9.0 in production, and have started noticing that statement errors abort an implicit transaction that never gets rolled back. This same issue doesn't appear on my development box, which is at 9.2. I'm not sure if it's a bug, feature, or configuration parameter at this point.

Here's an example of the problem:

$ psql test
test=> SELECT foo;
ERROR:  column "foo" does not exist
LINE 1: select foo;
ERROR:  current transaction is aborted, commands ignored until end of transaction block

Of course, I don't have a transaction to begin with. I realize that PostgreSQL wraps all statements in an implicit single-statement transaction, but in my experience it's never needed to be rolled back when there's an error. I don't require an explicit rollback on my local development instance of PostgreSQL.

The only relevant information I've been able to find online indicated it's a result of AUTOCOMMIT being off, but it's set to on in both environments.

So what is this? A bug? A misconfiguration? How do I resolve it?

share|improve this question
Interestingly, it works if I connect with the psql client from my development box. Is this possibly a buggy version of libpq? – Stephen Touset Dec 20 '12 at 0:48
Upgraded libpq and psql, no luck. – Stephen Touset Dec 20 '12 at 19:14
up vote 1 down vote accepted

Run this command in the psql client:


If it says "off", then look for a .psqlrc file that contains either "\set AUTOCOMMIT off" or "\unset AUTOCOMMIT".

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.