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 (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers