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 по дате отправления: