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@gmail.com
