Search Postgresql Archives

Re: query locks up when run concurrently

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/24/2016 02:14 PM, azhwkd wrote:

Adrian Klaver <adrian.klaver@xxxxxxxxxxx
<mailto:adrian.klaver@xxxxxxxxxxx>> 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 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?


The application is written in go. Every group ID has its own go routine
and the routine is blocked until the SQL statement returns.
The update process starts with a check to an external API endpoint and
if there is new data available the routine is downloading it, parsing it
and inserting the data into 2 tables. Once that is done, the routine
continues to execute the statement in question using the data it
inserted before for the calculation. Only once this finishes will the
routine start over again.



    > 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 inspected it visually and also dumped all variables into a file
directly from the application.



    > 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?


Do you mean if it always locks on the same parameters? If so then it
does not, sadly


Yes, that would have been too easy. I'm out of ideas for the moment. Rob Stones post looks promising though.


--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx


--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux