From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Craig Vosburgh <craig(dot)vosburgh(at)cassatt(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Hung SQL Update Linux Redhat 4U5 Postgres 8.3.1 |
Date: | 2008-05-09 23:49:58 |
Message-ID: | 8305.1210376998@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Craig Vosburgh <craig(dot)vosburgh(at)cassatt(dot)com> writes:
> We've dumped the locks and it shows that all locks have been granted so
> it appears that it is not a lock that is standing in our way. We've
> also gone in via psql while the update is hung and were able to perform
> an update on the offending table without issue. Finally, we have also
> enabled the statement_timeout and set it to five minutes and it does
> timeout the hung update and return to normal processing by rolling back
> the offending transaction but that's not a viable solution for us.
> Anyone have any words of wisdom on how to track this down?
For starters, attach to the hung backend with gdb and get a stack trace ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2008-05-10 05:35:36 | Re: dynamic procedure call |
Previous Message | Craig Vosburgh | 2008-05-09 22:57:05 | Hung SQL Update Linux Redhat 4U5 Postgres 8.3.1 |