Re: query locks up when run concurrently

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, the implication is that a group id can be reused so
what determines that?

> I watched the queries in a postgres client and there was no overlap I could see.

Was this a visual inspection or did you dump the results of the various
query/parameter combinations into tables and do an SQL comparison?

> I don't really know what to make from this behavior, sometimes when I
> start the application a few updates go through and eventually it will
> lock up completely and sometimes it locks up immediately - always with

Is there a common thread with regard to the parameters in use when
things lock up?

> heap_hot_search_buffer using ~20 of all CPU time on the system.
>
> 2016-11-24 19:14 GMT+01:00 Adrian Klaver <adrian.klaver@aklaver.com>:
>> 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?
>>



--
Adrian Klaver
adrian.klaver@aklaver.com