Re: Retain dynamic shared memory segments for postmaster lifetime - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Retain dynamic shared memory segments for postmaster lifetime
Date
Msg-id CA+TgmobvKbC+pMzYTj51nhCs_Us0Jwy5Lojs1B-WDpBeMpPkww@mail.gmail.com
Whole thread Raw
In response to Re: Retain dynamic shared memory segments for postmaster lifetime  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Mon, Mar 10, 2014 at 11:26 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Mon, Mar 10, 2014 at 11:37 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Looks good, committed.  However, I changed it so that
>> dsm_keep_segment() does not also perform the equivalent of
>> dsm_keep_mapping(); those are two separate operations.
>
> So are you expecting that if some one needs to retain dynamic segment's
> till PM lifetime, they should call both dsm_keep_segment() and
> dsm_keep_mapping()?

If they want to keep both the mapping and the segment, yes.  But in
general those two things are independent of each other.  A process
could want to map the segment and store some data in it, and then it
could want to unmap the segment; and then later the segment could be
mapped again (perhaps from some other backend) to get the data out.

> If we don't call both, it can lead to following warning:
> postgres=# select dsm_demo_create('this message is from session-new', 1);
> WARNING:  dynamic shared memory leak: segment 1402373971 still referenced

Well, that's just an artifact of the coding of dsm_demo_create().
Code that doesn't use dsm_keep_mapping() needs to be sure to call
dsm_detach() in the non-error path.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: db_user_namespace a "temporary measure"
Next
From: Simon Riggs
Date:
Subject: Re: Why is AccessShareLock held until end of transaction?