| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: on_exit_reset fails to clear DSM-related exit actions |
| Date: | 2014-03-17 15:32:36 |
| Message-ID: | 17143.1395070356@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-03-17 15:35:03 | Re: HEAD seems to generate larger WAL regarding GIN index |
| Previous Message | Tom Lane | 2014-03-17 15:28:45 | Re: First-draft release notes for next week's releases |