From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | amit(dot)kapila16(at)gmail(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Retain dynamic shared memory segments for postmaster lifetime |
Date: | 2014-02-06 10:12:13 |
Message-ID: | 20140206.191213.249997603.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello, I've understood how this works and seems working as
expected.
> Anyway this is just a test module so if things works for you by
> changing the above way, its fine. However I wonder why its not
> generating .def file for you.
Surely.
Getting back on topic, using dsm_keep_segment, I saw postmaster
keeping the section handle for the dsm segment and any session
ever after the creating session gone off could recall the
segment, unlike dsm_keep_mapping couldn't retain them after end
of the creating session. And this exactly resembles linux version
in behavior including attach failure.
The orphan section handles on postmaster have become a matter of
documentation.
Besides all above, I'd like to see a comment for the win32 code
about the 'DuplicateHandle hack', specifically, description that
the DuplicateHandle pushes the copy of the section handle to the
postmaster so the section can retain for the postmaster lifetime.
By the way I have one additional comment.
All postgres processes already keep a section handle for
'Global/PostgreSQL:<pgdata file path>' aside from dsm. It tells
itself is for the file. On the other hand the names for the dsm
sections are 'Global/PostgreSQL.%d'. This seems a bit unkindly as
they don't tell what they are of. Do you mind changing it to,
say, 'Global/PostgreSQL.dsm.%d' or something like that?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2014-02-06 10:21:57 | Re: GIN improvements part2: fast scan |
Previous Message | Emre Hasegeli | 2014-02-06 10:03:00 | Re: GiST support for inet datatypes |