Re: Possible problem with shm_mq spin lock

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Possible problem with shm_mq spin lock
Дата
Msg-id 21963.1414285932@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Possible problem with shm_mq spin lock  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Ответы Re: Possible problem with shm_mq spin lock
Re: Possible problem with shm_mq spin lock
Список pgsql-hackers
Haribabu Kommi <kommi.haribabu@gmail.com> writes:
> Thanks for the details. I am sorry It is not proc_exit. It is the exit
> callback functions that can cause problem.

> The following is the callstack where the problem can happen, if the signal
> handler is called after the spin lock took by the worker.

> Breakpoint 1, 0x000000000072dd83 in shm_mq_detach ()
> (gdb) bt
> #0  0x000000000072dd83 in shm_mq_detach ()
> #1  0x000000000072e7db in shm_mq_detach_callback ()
> #2  0x0000000000726d71 in dsm_detach ()
> #3  0x0000000000726c43 in dsm_backend_shutdown ()
> #4  0x0000000000727450 in shmem_exit ()
> #5  0x00000000007272fc in proc_exit_prepare ()
> #6  0x0000000000727501 in atexit_callback ()
> #7  0x00000030ff435da2 in exit () from /lib64/libc.so.6
> #8  0x00000000006ddaec in bgworker_quickdie ()

Or in other words, Robert broke it.  This control path should absolutely
not occur: the entire point of the on_exit_reset call in quickdie() is to
prevent any callbacks from being executed when we get to shmem_exit().
DSM-related functions DO NOT get an exemption.
        regards, tom lane



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

Предыдущее
От: Haribabu Kommi
Дата:
Сообщение: Re: Possible problem with shm_mq spin lock
Следующее
От: Haribabu Kommi
Дата:
Сообщение: Re: Possible problem with shm_mq spin lock