Re: not aborting transactions on failed select

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.

In response to

Responses

Browse pgsql-general by date

  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