Re: Deadlock on "select ... for update"?

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Craig James <craig_james(at)emolecules(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Deadlock on "select ... for update"?
Date: 2011-11-29 18:36:20
Message-ID: CAOR=d=1Dr8mzoXXr93-ev4pQqK=SsD=eJeHPkDzjTddfg6DTqQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Tue, Nov 29, 2011 at 11:15 AM, Craig James
<craig_james(at)emolecules(dot)com> wrote:
> Several times recently one of our databases has gotten stuck with the
> following situation:
>
> postgres=# select datname, procpid, usename, current_query from
> pg_stat_activity where current_query != '<IDLE>';
>   datname   | procpid | usename  |
>   current_query
> ------------+---------+----------+--------------------------------------------------------------------------------------------------------
>  emolecules |   13503 | customerdb | select tableid from hitlist_table_pool
> where hitlistid <= 0 for update
>  emolecules |   32082 | customerdb | select tableid from hitlist_table_pool
> where hitlistid <= 0 for update
>  emolecules |   17974 | customerdb | select tableid from hitlist_table_pool
> where hitlistid <= 0 for update
>  emolecules |   31299 | customerdb | select tableid from hitlist_table_pool
> where hitlistid = 0 limit 1 for update
>  emolecules |   30247 | customerdb | select tableid from hitlist_table_pool
> where hitlistid = 0 limit 1 for update
>  postgres   |    1705 | postgres | select datname, procpid, usename,
> current_query from pg_stat_activity where current_query != '<IDLE>';
>  emolecules |   28866 | customerdb | <IDLE> in transaction
>  emolecules |   21394 | customerdb | select tableid from hitlist_table_pool
> where hitlistid = 0 limit 1 for update
>  emolecules |   22237 | customerdb | select tableid from hitlist_table_pool
> where hitlistid = 0 limit 1 for update
> (9 rows)
>
> It's obvious that they're all waiting ... but for what?  The "<IDLE>"
> process looks like the culprit, but how do I figure out what it's doing?
> The next time this happens, what queries can I run to help diagnose what's
> going on?
> This is PG 8.4.4 on Ubuntu 10.

Does this help?

http://wiki.postgresql.org/wiki/Lock_Monitoring

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Kevin Grittner 2011-11-29 18:55:16 Re: transaction error handling
Previous Message Rob Richardson 2011-11-29 18:34:49 Re: transaction error handling