Hello,
> Currently there is no way user can keep the dsm
> segments if he wants for postmaster lifetime, so I
> have exposed a new API dsm_keep_segment()
> to implement the same.
I had a short look on this patch.
- DSM implimentation seems divided into generic part (dsm.c) and platform dependent part(dsm_impl.c). This
dsm_keep_segment puts WIN32 specific part directly into dms.c. I suppose it'd be better defining DSM_OP_KEEP_SEGMENT
andcalling dms_impl_op from dms_keep_segment, or something.
- Repeated calling of dsm_keep_segment even from different backends creates new (orphan) handles as many as it is
called. Simplly invoking this function in some of extensions intending to stick segments might results in so many
orphan handles. Something to curb that situation would be needed.
- "Global/PostgreSQL.%u" is the same literal constant with that occurred in dsm_impl_windows. It should be defined as
a constant (or a macro).
- dms_impl_windows uses errcode_for_dynamic_shared_memory() for ereport and it finally falls down to
errcode_for_file_access().I think it is preferable, maybe.
> The specs and need for this API is already discussed
> in thread:
> http://www.postgresql.org/message-id/CA+TgmoaKoGuJQbEdGeYKYSXud9EAidqx77J2_HXzRgFo3Hr46A@mail.gmail.com
>
> I had used dsm_demo (hacked it a bit) module used
> during initial tests for dsm API's to verify the working on
> Windows. So one idea could be that I can extend
> that module to use this new API, so that it can be tested
> by others as well or if you have any other better way, please
> do let me know.
I'll run on windows sooner:-)
> As the discussion about its specs and need is already
> discussed in above mentioned thread, so I will upload
> this patch to CF unless there is any Objection.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center