On Mon, Mar 10, 2014 at 12:44 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Mon, Mar 10, 2014 at 9:48 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> On Mon, Mar 10, 2014 at 8:18 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> I took a look at this patch. It seems to me that it doesn't do a very
>>> good job maintaining the abstraction boundary between what the dsm.c
>>> layer knows about and what the dsm_impl.c layer knows about. However,
>>> AFAICS, these problems are purely cosmetic, so I took a crack at
>>> fixing them. I retitled the new implementation-layer function to
>>> dsm_impl_keep_segment(), swapped the order of the arguments for
>>> consistency with other code, adjusted the dsm_impl.c code slightly to
>>> avoid assuming that only the Windows implementation works on Windows
>>> (that's currently true, but we could probably make the mmap
>>> implementation work there as well), and retooled some of the comments
>>> to read better in English. I'm happy with the attached version but
>>> don't have a Windows box to test it there.
>>
>> Thank you for looking into patch. I have verified that attached patch
>> works fine on Windows.
>>
>> One observation in new version of patch:
>>
>> + {
>> + char name[64];
>> +
>> + snprintf(name, 64, "%s.%u", SEGMENT_NAME_PREFIX, handle);
>> + _dosmaperr(GetLastError());
>> + ereport(ERROR,
>> + (errcode_for_dynamic_shared_memory(),
>> + errmsg("could not duplicate handle: %m")));
>> + }
>
> I have updated the patch to change message as below:
> errmsg("could not duplicate handle for \"%s\": %m",
> name)));
>
> Let me know your suggestions?
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company