Re: not aborting transactions on failed select
От | Scott Marlowe |
---|---|
Тема | Re: not aborting transactions on failed select |
Дата | |
Msg-id | CAOR=d=3Czoi4jTFs9_aqKMN+DJ7u86CyU24vDEyPRkGTfoK3Dg@mail.gmail.com обсуждение исходный текст |
Ответ на | not aborting transactions on failed select (Sergey Shelukhin <sergey@hortonworks.com>) |
Ответы |
Re: not aborting transactions on failed select
|
Список | pgsql-general |
On Tue, Sep 10, 2013 at 7:02 PM, Sergey Shelukhin <sergey@hortonworks.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.
В списке pgsql-general по дате отправления: