| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)heroku(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: LWLock deadlock and gdb advice |
| Date: | 2015-06-30 06:28:47 |
| Message-ID: | CAMkU=1wL4WDyNmBLrmztdhpmgjMM_CPAStcxbtAOvk+Q16sy5g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jun 29, 2015 at 5:55 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Mon, Jun 29, 2015 at 5:37 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> > Is there a way to use gdb to figure out who holds the lock they are
> waiting
> > for?
>
> Have you considered building with LWLOCK_STATS defined, and LOCK_DEBUG
> defined? That might do it.
>
I hadn't planned on running into this problem, so had not compiled
accordingly.
I thought LOCK_DEBUG would produce too much output, but now I see it
doesn't print anything unless Trace_lwlocks is on (but it still makes more
info available to gdb, as Amit mentioned), so I think that should be OK.
Since I messed up the gdb session causing the postmaster to SIGKILL all the
children and destroy the evidence, I'll repeat the run compiled with
LOCK_DEBUG and see what it looks like in the morning.
Thanks,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2015-06-30 06:30:39 | Re: Reduce ProcArrayLock contention |
| Previous Message | Simon Riggs | 2015-06-30 06:23:58 | Re: Reduce ProcArrayLock contention |