From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Retain dynamic shared memory segments for postmaster lifetime |
Date: | 2014-03-11 17:23:06 |
Message-ID: | CA+TgmobvKbC+pMzYTj51nhCs_Us0Jwy5Lojs1B-WDpBeMpPkww@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 10, 2014 at 11:26 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Mon, Mar 10, 2014 at 11:37 PM, Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2014-03-11 17:26:23 | Re: Why is AccessShareLock held until end of transaction? |
Previous Message | Andrew Dunstan | 2014-03-11 16:43:11 | Re: db_user_namespace a "temporary measure" |