Re: on_exit_reset fails to clear DSM-related exit actions

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: Raw Message | Whole Thread | 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

In response to

Responses

Browse pgsql-hackers by date

  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