From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | snpe <snpe(at)snpe(dot)co(dot)yu> |
Cc: | "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: problem with new autocommit config parameter and jdbc |
Date: | 2002-09-10 02:27:03 |
Message-ID: | 15685.1031624823@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
snpe <snpe(at)snpe(dot)co(dot)yu> writes:
> I'm use 'autocommit=false' and have problem with psql
> When any commnad is lost, then next commnad get error for transactions
> (simple select command).BTW
> snpe> select * from org_ba;
> ERROR: relation org_ba does not exists
> snpe> select * from org_ban;
> ERROR: current transactions is aborted, queries ignored until end of
> transaction block
Um, what's wrong with that?
It seems to me that an application that is using autocommit=off will
expect the first SELECT to start a transaction block. If the first
SELECT fails, then subsequent commands *should* fail until you commit
or rollback. Certainly if you did an explicit BEGIN before the first
SELECT, the above is what you'd get --- why should implicit BEGIN
work differently?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2002-09-10 02:36:44 | Re: Proposal: Solving the "Return proper affected tuple |
Previous Message | Bruce Momjian | 2002-09-10 02:24:19 | Re: Proposal: Solving the "Return proper effected tuple |
From | Date | Subject | |
---|---|---|---|
Next Message | Curt Sampson | 2002-09-10 02:51:21 | Re: problem with new autocommit config parameter and jdbc |
Previous Message | Stephan Szabo | 2002-09-10 02:16:47 | Re: problem with new autocommit config parameter and jdbc |