On Mon, Mar 10, 2014 at 11:26 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Mon, Mar 10, 2014 at 11:37 PM, Robert Haas <robertmh...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to