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 s
I don't need local sorting, I only had to retrieve some objects from db
belongs to user.
A this point is it better unlogged tables or postgres object arrays?
Il 06/feb/2014 09:35 "alexandros_e [via PostgreSQL]" <
ml-node+s1045698n5790806...@n5.nabble.com> ha scritto:
> @mephysto I think you are t
@mephysto I think you are trying to solve the wrong type of problem. Creation
of tables (temporary or not) are not supposed to run concurrently. So, this
is not an issue of PostgreSQL but design. There are two ways to solve the
problem.
a) You could use the sessionID (provided The Glassfish server
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 tempor
On 02/05/2014 12:19 PM, Mephysto wrote:
I posted my last message via Nabble, so I think that the log is not
shown in email.
I try to repost my log via email:
DEBUG: building index "pg_toast_148085_index" on table "pg_toast_148085"
CONTEXT: SQL statement "CREATE LOCAL TEMPORARY TABLE deck_ty
On 05 Feb 2014, at 21:19, Mephysto wrote:
> I posted my last message via Nabble, so I think that the log is not shown in
> email.
>
>
> I try to repost my log via email:
>
> DEBUG: building index "pg_toast_148085_index" on table "pg_toast_148085"
> CONTEXT: SQL statement "CREATE LOCAL TEMP
I posted my last message via Nabble, so I think that the log is not shown
in email.
I try to repost my log via email:
DEBUG: building index "pg_toast_148085_index" on table "pg_toast_148085"
CONTEXT: SQL statement "CREATE LOCAL TEMPORARY TABLE deck_types
ON COMMIT DROP
On 02/05/2014 07:36 AM, mephysto wrote:
Ehm no,
at a few line befor end you can read this:
ERROR: relation "deck_types" already exists
I should have been clearer. There is no error log posted in your
previous message.
So, the error persists.
:(
--
View this message in context:
htt
Ehm no,
at a few line befor end you can read this:
ERROR: relation "deck_types" already exists
So, the error persists.
:(
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Temporary-table-already-exists-tp5789852p5790688.html
Sent from the PostgreSQL - general mailin
On 02/05/2014 07:19 AM, mephysto wrote:
Hello newly,
this is my error log:
Thanks in advance.
Seems problem is solved:)
Meph
--
Adrian Klaver
adrian.kla...@gmail.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www
Hello newly,
this is my error log:
Thanks in advance.
Meph
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Temporary-table-already-exists-tp5789852p5790682.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-general maili
mephysto wrote:
> Is it possible that it is read-uncommitted transaction isolation level?
No; there is no such thing in PostgreSQL.
The lowest isolation level is READ COMMITTED.
Yours,
Laurenz Albe
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your s
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 wou
Dmitriy Igrishin wrote
> 2014-01-31 Albe Laurenz <
> laurenz.albe@.gv
> >:
>
>> mephysto wrote:
>> > Hi Albe, this is code of my stored function:
>> > CREATE OR REPLACE FUNCTION :FUNCTION_SCHEMA.get_deck_types
>> [...]
>> > BEGIN
>> [...]
>> > CREATE LOCAL TEMPORARY T
2014-01-31 Albe Laurenz :
> mephysto wrote:
> > Hi Albe, this is code of my stored function:
> > CREATE OR REPLACE FUNCTION :FUNCTION_SCHEMA.get_deck_types
> [...]
> > BEGIN
> [...]
> > CREATE LOCAL TEMPORARY TABLE deck_types
> > ON COMMIT DROP
> >
Thank you Felix,
but I would to create temporary table from stored procedure, non from
application code.
Thanks again.
Meph
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Temporary-table-already-exists-tp5789852p5789877.html
Sent from the PostgreSQL - general mailing
Id + "( ... ) on commit preserve rows");
etc.
Then you have to add the tmpTableId to every statement in your code but it should work fine.
Gesendet: Freitag, 31. Januar 2014 um 12:04 Uhr
Von: mephysto
An: pgsql-general@postgresql.org
Betreff: Re: [GENERAL] Temporary table already
mephysto wrote:
> Hi Albe, this is code of my stored function:
> CREATE OR REPLACE FUNCTION :FUNCTION_SCHEMA.get_deck_types
[...]
> BEGIN
[...]
> CREATE LOCAL TEMPORARY TABLE deck_types
> ON COMMIT DROP
> AS
> SELECT
> stored_fu
Hi Albe,this is code of my stored function:ConnectionPool reuse connections,
of course, but how you can see from my code, the temporary table deck_types
are already defined with ON COMMIT DROP clause, so I think that my work is
not in transaction. Am I true?If so, how can I put my code in
transacti
mephysto wrote:
> in my database I'm using several stored_functions that take advantage of
> temporary table. The application that is connected to Postgres is a Java Web
> Application in a Glassfish Application Server: it is connected by a JDBC
> Connection Pool provided by Glassfish with this sett
Hi there,
in my database I'm using several stored_functions that take advantage of
temporary table. The application that is connected to Postgres is a Java Web
Application in a Glassfish Application Server: it is connected by a JDBC
Connection Pool provided by Glassfish with this settings:
Resourc
21 matches
Mail list logo
