Re: "stuck spinlock"

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: "stuck spinlock"
Дата
Msg-id CAM3SWZR9FOkDmjT4i2Z+rzLjstzoJRzuOc-tb6CX7+kf7Lx6pw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: "stuck spinlock"  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Dec 12, 2013 at 5:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Memo to hackers: I think the SIGSTOP stuff is rather obsolete now that
> most systems dump core files with process IDs embedded in the names.
> What would be more useful today is an option to send SIGABRT, or some
> other signal that would force core dumps.  Thoughts?

I think it would be possible, at least on Linux, to have GDB connect
to the postmaster, and then automatically create new inferiors as new
backends are forked, and then have every inferior paused as
breakpoints are hit. See:

http://sourceware.org/gdb/onlinedocs/gdb/Forks.html

and

http://sourceware.org/gdb/onlinedocs/gdb/All_002dStop-Mode.html

(I think the word 'thread' is just a shorthand for 'inferior' in the
"stops mode" doc page, and you can definitely debug Postgres processes
in multiple inferiors today).

Now, I'm not sure how feasible this is in a production debugging
situation. It seems like an interesting way of debugging these sorts
of issues that should be explored and perhaps subsequently codified.

-- 
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: "stuck spinlock"
Следующее
От: Andres Freund
Дата:
Сообщение: Re: "stuck spinlock"