From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | Alexander Farber <alexander(dot)farber(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Optimizing select count query which often takes over 10 seconds |
Date: | 2013-01-30 13:06:57 |
Message-ID: | 1359551217.83456.YahooMailNeo@web162904.mail.bf1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Alexander Farber <alexander(dot)farber(at)gmail(dot)com> wrote:
> The cronjob gives me now occasionally:
>
> /* reset and then update medals count */
> update pref_users set medals = 0;
> psql:/home/afarber/bin/clean-database.sql:63: ERROR: deadlock detected
> DETAIL: Process 31072 waits for ShareLock on transaction 124735679; blocked by process 30368.
> Process 30368 waits for ShareLock on transaction 124735675; blocked by process 31072.
> HINT: See server log for query details.
> Any ideas please how to workaround?
Yeah, try this:
update pref_users set medals = 0 where medals <> 0;
:-)
That should significantly reduce the frequency of deadlocks;
however, IMO any application using a relational database should be
prepared to retry database transactions which fail with a
serialization error, and a deadlock is one form of that. The
standard SQLSTATE to look for is '40001' and in PostgreSQL you
should also check for '40P01'.
-Kevin
From | Date | Subject | |
---|---|---|---|
Next Message | C. Bensend | 2013-01-30 13:12:26 | Re: pg_Restore |
Previous Message | Kevin Grittner | 2013-01-30 12:58:41 | Re: Optimizing select count query which often takes over 10 seconds |