Skip site navigation (1) Skip section navigation (2)

Re: Runtime parameter holding is_in_transaction state

From: Sergey Samokhin <prikrutil(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-novice(at)postgresql(dot)org
Subject: Re: Runtime parameter holding is_in_transaction state
Date: 2009-09-06 16:38:19
Message-ID: e42595410909060938o3f79530ct33354e5c8b36f0bf@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-novice
Hello.

> Maybe you should explain what it is you want to accomplish.

Thanks for your answer, Tom! It caused me to start looking for another
solution rather than looking for such a variable.

The original purpose of asking the question was to find a way to
detect that a transaction passed to my server as one big string has
failed:

// This transaction will never succeed because there is an UPDATE of
non existing table
// To gracefully get things back I should detect the failure and do ROLLBACK
"BEGIN; UPDATE non_existing_table SET foo = 42; <skipped> ; COMMIT;"

One way to detect that would be to check if we are still in
transaction by SHOW'ing some variable. It seemed like what I should
try, because every faulty query leaves its transaction opened. In any
way, this solution is much more expensive than conventional traversing
the list of results which my driver returns for each complex query.

Now when I've chosen a way to check if such a complex query
(containing several SQL-commands) failed, I no longer want such a
parameter to exist in PG.

-- 
Sergey Samokhin

In response to

pgsql-novice by date

Next:From: Jignesh ShahDate: 2009-09-07 09:33:09
Subject: require some suggestion to write trigger function
Previous:From: Joshua TolleyDate: 2009-09-05 03:22:22
Subject: Re: Where to report a bug?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group