Re: on_exit_reset fails to clear DSM-related exit actions
От | Tom Lane |
---|---|
Тема | Re: on_exit_reset fails to clear DSM-related exit actions |
Дата | |
Msg-id | 1665.1394466489@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: on_exit_reset fails to clear DSM-related exit actions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: on_exit_reset fails to clear DSM-related exit actions
Re: on_exit_reset fails to clear DSM-related exit actions |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Fri, Mar 7, 2014 at 2:40 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> Hmm. So the problematic sequence of events is where a postmaster >> child forks, and then exits without exec-ing, perhaps because e.g. >> exec fails? > I've attempted a fix for this case. The attached patch makes > test_shm_mq fork() a child process that calls on_exit_reset() and then > exits. Without the fix I just pushed, this causes the tests to fail; > with this fix, this does not cause the tests to fail. > I'm not entirely sure that this is exactly right, but I think it's an > improvement. This looks generally sane to me, but I wonder whether you should also teach PGSharedMemoryDetach() to physically detach from DSM segments not just the main shmem seg. Or maybe better, adjust most of the places that call on_exit_reset and then PGSharedMemoryDetach to also make a detach-from-DSM call. It looks like both sysv_shmem.c and win32_shmem.c have internal callers of PGSharedMemoryDetach, which probably shouldn't affect DSM. You could argue that that's unnecessary on the grounds that the postmaster will never have any DSM segments attached, but I think it would be good coding practice anyway. People who copy-and-paste those bits of code into other places are not likely to think of adding DSM calls. regards, tom lane
В списке pgsql-hackers по дате отправления: