Re: on_exit_reset fails to clear DSM-related exit actions

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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-10 20:18:03
Message-ID: 20140310201803.GM4759@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas escribió:

> A related point that's been bugging me for a while, and has just
> struck me again, is that background workers for which
> BGWORKER_SHMEM_ACCESS is not passed probably ought to be detaching
> shared memory (and DSMs). Currently, and since Alvaro originally
> added the facility, the death of a non-BGWORKER_SHMEM_ACCESS backend
> is used in postmaster.c to decide whether to call HandleChildCrash().
> But such workers could still clobber shared memory arbitrarily; they
> haven't unmapped it. Oddly, the code in postmaster.c is only cares
> about the flag when checking EXIT_STATUS_0()/EXIT_STATUS_1(), not when
> checking ReleasePostmasterChildSlot()...

Clearly there's not a lot of consistency on that. I don't think I had
made up my mind completely about such details. I do remember that
unmapping/detaching the shared memory segment didn't cross my mind; the
flag, as I recall, only controls (controlled) whether to attach to it
explicitely.

IOW feel free to whack around.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Berry 2014-03-10 20:52:04 Re: calculating an aspect of shared buffer state from a background worker
Previous Message Thom Brown 2014-03-10 20:00:50 Re: GSoC 2014 - mentors, students and admins