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-02-06 12:37:33 |
Message-ID: | 52F3820D.6070104@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 02/06/2014 12:09 AM, mephysto wrote:
> Hi Adrian,
> it is not an artifact. This log comes from a multiplayer game, and this
> is an specific test to replicate the error. Practically, there are two
> users that execute the same operation, so you can see the simultaneous
> selects.
>
> My opinion was every session was isolated from others and temporary
> table was atomic for every session (transaction).
Well sessions and transactions are not the same thing. A simple
explanation:
A session is a specific connection to a database.
A transaction is a unit of work. It can be explicitly bounded by
BEGIN/COMMIT(ROLLBACK). In Postgres if you do not supply the BEGIN each
statement gets one, so each statement is in a transaction.
So a session can have one transaction or multiple.
>
> But I think that I'm not true.
>
> Are The two selects in the same session in my case? Why?
The issue to me at least, assuming Postgres is working properly, is that
you have two selects in the same transaction. The ON COMMIT DROP should
drop the table at the end of the transaction. Now as Alban wrote it is
possible that the table is being cached somehow. One suggestion I on
that line of thought is to use dynamic commands:
It is also possible, as mentioned previously, that the Java code is
misbehaving. That there are threads interfering with each other. I am
not a Java programmer so I can not be of any help there.
>
> Thanks in advance.
>
> Mephysto
>
>
>
--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Rémi Cura | 2014-02-06 12:45:14 | Re: Ordering Results by a Supplied Order |
Previous Message | Adrian Klaver | 2014-02-06 11:47:29 | Re: client encoding that psql command sets |