On Sun, Oct 26, 2014 at 12:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Haribabu Kommi <kommi.harib...@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.
The "reset_on_dsm_detach" function is called to remove the DSM related callbacks. It's my mistake, I am really sorry, the code I am using is a wrong one. Sorry for the noise. Regards, Hari Babu Fujitsu Australia -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
