From: | Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> |
---|---|
To: | mephysto <mephystoonhell(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Temporary table already exists |
Date: | 2014-01-31 15:04:48 |
Message-ID: | 52EBBB90.20000@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 01/31/2014 06:49 AM, mephysto wrote:
> Dmitriy Igrishin wrote
>> 2014-01-31 Albe Laurenz <
>
>> laurenz(dot)albe(at)(dot)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(dot)klaver(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Vick Khera | 2014-01-31 15:04:49 | postgres cache vs ZFS cache |
Previous Message | mephysto | 2014-01-31 14:49:15 | Re: Temporary table already exists |