> 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 and calling 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_hxzrgfo3hr...@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.


Kyotaro Horiguchi
NTT Open Source Software Center

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

Reply via email to