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