Greetings!
I tried running the application using the race detector but no data races
were detected.
To further narrow this down I removed the call to the function in question
from the pool
and instead run it one by one from a queue. This seems to have helped and
the query didn't lock up anymore.
I
On 11/24/2016 02:14 PM, azhwkd wrote:
Adrian Klaver mailto:adrian.kla...@aklaver.com>> schrieb am Do., 24. Nov. 2016 um
22:34 Uhr:
On 11/24/2016 01:23 PM, azhwkd wrote:
> It should not be possible because a group does not return to the
> update pool before the update hasn't finished
On Thu, 2016-11-24 at 22:23 +0100, azhwkd wrote:
> It should not be possible because a group does not return to the
> update pool before the update hasn't finished.
> I watched the queries in a postgres client and there was no overlap I
> could see.
> I don't really know what to make from this beh
Adrian Klaver schrieb am Do., 24. Nov. 2016 um
22:34 Uhr:
> On 11/24/2016 01:23 PM, azhwkd wrote:
> > It should not be possible because a group does not return to the
> > update pool before the update hasn't finished.
>
> So what is this 'update pool' and what is driving/using it?
>
> In other wo
On 11/24/2016 01:23 PM, azhwkd wrote:
It should not be possible because a group does not return to the
update pool before the update hasn't finished.
So what is this 'update pool' and what is driving/using it?
In other words how is the determination of the parameters done?
To be more specific
It should not be possible because a group does not return to the
update pool before the update hasn't finished.
I watched the queries in a postgres client and there was no overlap I could see.
I don't really know what to make from this behavior, sometimes when I
start the application a few updates
On 11/23/2016 10:41 PM, azhwkd wrote:
The group ID is part of the primary key of the group_history table. My
understanding is that two INSERTs with different group IDs should not
collide in this case, or am I wrong in thinking this?
After fresh coffee:
In your first post you had this:
"(In the
On 11/23/2016 10:41 PM, azhwkd wrote:
The group ID is part of the primary key of the group_history table. My
understanding is that two INSERTs with different group IDs should not
collide in this case, or am I wrong in thinking this?
The table definition for group_history is the following:
CREAT
On 11/23/2016 10:41 PM, azhwkd wrote:
The group ID is part of the primary key of the group_history table. My
understanding is that two INSERTs with different group IDs should not
collide in this case, or am I wrong in thinking this?
The suspicion is that this:
insert into group_history ("group
On 11/23/2016 10:26 PM, azhwkd wrote:
I'm sorry. I worded this quite poorly. I meant to say that there were
no log lines added to the postgres logfile at the time.
I hope these are the settings you were refferring to (I did not change
anything in the config files vs. the default)
log_destination
The group ID is part of the primary key of the group_history table. My
understanding is that two INSERTs with different group IDs should not
collide in this case, or am I wrong in thinking this?
The table definition for group_history is the following:
CREATE TABLE public.group_history (
group int
I'm sorry. I worded this quite poorly. I meant to say that there were
no log lines added to the postgres logfile at the time.
I hope these are the settings you were refferring to (I did not change
anything in the config files vs. the default)
log_destination = 'stderr'
logging_collector = off
log_
On 11/23/2016 01:52 PM, azhwkd wrote:
Greetings!
The parallel calls should not be working on the same row. Each query
services a different group ID on it's own and there is no overlap.
Except the INSERT query in the trigger function is working on dates not
group ids.
Kind regards,
Sebasti
On 11/23/2016 01:47 PM, azhwkd wrote:
Greetings!
Yes I had a look at the logfiles but there is not a single logfile
generated when I'm reproducing this issue.
We are talking about the Postgres logfile, correct?
I have to believe a log file exists, but maybe not entries at that time.
What are
Greetings!
The parallel calls should not be working on the same row. Each query
services a different group ID on it's own and there is no overlap.
Kind regards,
Sebastian
Tom Lane schrieb am Mi., 23. Nov. 2016 um 17:47 Uhr:
> azh...@gmail.com writes:
> > I have a query which if run alone usua
Greetings!
Yes I had a look at the logfiles but there is not a single logfile
generated when I'm reproducing this issue.
Concerning locks I used there queries at
https://wiki.postgresql.org/wiki/Lock_Monitoring and they came up empty.
The group_history table and its sub-tables do not have any fore
Greetings!
I'm using postgres version 9.5.5 on a ubuntu 16.04.1 server
installation which was installed through apt-get.
I have a query which if run alone usually completes in about 300ms.
When run in my application this query constantly locks up and bogs
down all connections of the connection po
azh...@gmail.com writes:
> I have a query which if run alone usually completes in about 300ms.
> When run in my application this query constantly locks up and bogs
> down all connections of the connection pool (In the application this
> query is run up to 10 times in parallel with different paramet
On 11/22/2016 11:41 PM, azh...@gmail.com wrote:
Greetings!
I'm using postgres version 9.5.5 on a ubuntu 16.04.1 server
installation which was installed through apt-get.
I have a query which if run alone usually completes in about 300ms.
When run in my application this query constantly locks up
Greetings!
I'm using postgres version 9.5.5 on a ubuntu 16.04.1 server
installation which was installed through apt-get.
I have a query which if run alone usually completes in about 300ms.
When run in my application this query constantly locks up and bogs
down all connections of the connection po
20 matches
Mail list logo
