From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Sergey Shelukhin <sergey(at)hortonworks(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: not aborting transactions on failed select |
Date: | 2013-09-11 04:39:45 |
Message-ID: | CAOR=d=3Czoi4jTFs9_aqKMN+DJ7u86CyU24vDEyPRkGTfoK3Dg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Sep 10, 2013 at 7:02 PM, Sergey Shelukhin
<sergey(at)hortonworks(dot)com> wrote:
> Hi.
> Is there any way to make postgres not abort the transaction on failed
> select?
>
> I have a system that uses ORM to retrieve data; ORM is very slow for some
> cases, so there's a perf optimization that issues ANSI SQL queries directly
> thru ORM's built-in passthru, and falls back to ORM if they fail.
> All of these queries are select-s, and the retrieval can be a part of an
> external transaction.
>
> It worked great in MySQL, but Postgres being differently ANSI-non-compliant,
> the queries do fail. Regardless of whether they can be fixed, in such cases
> the fall-back should work. What happens in Postgres however is that the
> transaction is aborted; all further SELECTs are ignored.
I would like to see the query and in what way PostgreSQL is failing.
Generally a query that works on mysql and fails on postgresql is
itself usually non-ansi compliant.
As others pointed out, you can use savepoints if you need to rollback
part of a transaction to a previously good point and start back from
there.
From | Date | Subject | |
---|---|---|---|
Next Message | tim truman | 2013-09-11 04:43:31 | autovacuum out of memory errors |
Previous Message | David Johnston | 2013-09-11 03:38:34 | Re: not aborting transactions on failed select |