On 01/31/2014 06:49 AM, mephysto wrote:
Dmitriy Igrishin wrote
2014-01-31 Albe Laurenz <
laurenz.albe@.gv
You could try to set log_statement to "all" and see what SQL actually
gets sent to the database.
You could also include "EXECUTE 'DROP TABLE deck_types';" in your
function.
I would recommend to use DISCARD ALL before returning the connection to
the
pool
anyway. But it's not about current problem. The OP's problem is about "why
ON COMMIT
DROP does not work".
--
// Dmitry.
Is it possible that it is read-uncommitted transaction isolation level?
No
http://www.postgresql.org/docs/9.3/interactive/transaction-iso.html#XACT-READ-COMMITTED
In PostgreSQL, you can request any of the four standard transaction
isolation levels. But internally, there are only three distinct
isolation levels, which correspond to the levels Read Committed,
Repeatable Read, and Serializable. When you select the level Read
Uncommitted you really get Read Committed...
The issue would seem to be here from you initial post:
"The problem is that in a concurrent execution of a function, I received
error of relation already exists."
Per a previous post you will need to crank up the logging and see
exactly how your statements are being sent to the back end.
--
Adrian Klaver
adrian.klaver@xxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
