Re: on_exit_reset fails to clear DSM-related exit actions
От | Robert Haas |
---|---|
Тема | Re: on_exit_reset fails to clear DSM-related exit actions |
Дата | |
Msg-id | CA+TgmoavDU2zRqXKK+9EQyPcWs7D=zfxmJwmhJ3spqM7-G6nig@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: on_exit_reset fails to clear DSM-related exit actions (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: on_exit_reset fails to clear DSM-related exit actions
|
Список | pgsql-hackers |
On Mon, Mar 17, 2014 at 11:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> One option is to just change that function to also unmap the control >> segment, and maybe rename it to dsm_detach_all(), and then use that >> everywhere. The problem is that I'm not sure we really want to incur >> the overhead of an extra munmap() during every backend exit, just to >> get rid of a control segment which was going to be unmapped anyway by >> process termination. For that matter, I'm not sure why we bother >> arranging that for the main shared memory segment, either: surely >> whatever function the shmdt() and munmap() calls in IpcMemoryDetach >> may have will be equally well-served by the forthcoming exit()? > > Before you lobotomize that code too much, consider the postmaster > crash-recovery case. That path does need to detach from the old > shmem segment. > > Also, I might be wrong, but I think IpcMemoryDetach is a *postmaster* > on_shmem_exit routine; it isn't called during backend exit. Ah, right. I verified using strace that, at least on Linux 2.6.32-279.el6.x86_64, the only system call made on disconnecting a psql session is exit_group(0). I also tried setting breakpoints on PGSharedMemoryDetach and IpcMemoryDetach and they do not fire. After mulling over a few possible approaches, I came up with the attached, which seems short and to the point. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: