Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL - Mailing list pgsql-hackers

<div class="moz-cite-prefix">On 05/01/2014 18:02, Robert Haas wrote:<br /></div><blockquote
cite="mid:CA+TgmoZ2EL2zdt=e4FONQPGjjn4Y2N=-cu7q+cS+vWRnDgnR+Q@mail.gmail.com"type="cite"><div class="moz-text-plain"
graphical-quote="true"lang="x-western" style="font-family: -moz-fixed; font-size: 14px;" wrap="true"><pre wrap="">On
Sun,Jan 5, 2014 at 12:34 PM, james <a class="moz-txt-link-rfc2396E" href="mailto:james@mansionfamily.plus.com"
moz-do-not-send="true"><james@mansionfamily.plus.com></a>wrote:
 
</pre><blockquote style="color: #000000;" type="cite"><pre wrap=""><span class="moz-txt-citetags">> </span>On
05/01/201416:50, Robert Haas wrote:
 
<span class="moz-txt-citetags">></span>
<span class="moz-txt-citetags">> </span> But on Windows, segments are <b class="moz-txt-star"><span
class="moz-txt-tag">*</span>automatically<spanclass="moz-txt-tag">*</span></b>
 
<span class="moz-txt-citetags">> </span>destroyed <b class="moz-txt-star"><span class="moz-txt-tag">*</span>by the
operatingsystem<span class="moz-txt-tag">*</span></b> when the last process unmaps them,
 
<span class="moz-txt-citetags">> </span>so it's not quite so clear to me how we can allow it there.  The main
<span class="moz-txt-citetags">> </span>shared memory segment is no problem because the postmaster always has
<span class="moz-txt-citetags">> </span>it mapped, even if no one else does, but that doesn't help for dynamic
<span class="moz-txt-citetags">> </span>shared memory segments.
<span class="moz-txt-citetags">></span>
<span class="moz-txt-citetags">> </span>Surely you just need to DuplicateHandle into the parent process?  If you
<span class="moz-txt-citetags">> </span>want to (tidily) dispose of it at some time, then you'll need to tell the
<span class="moz-txt-citetags">> </span>postmaster that you have done so and what the handle is in its process,
<span class="moz-txt-citetags">> </span>but if you just want it to stick around, then you can just pass it up.
</pre></blockquote><pre wrap="">Uh, I don't know, maybe?  Does the postmaster have to do something to
receive the duplicated handle</pre></div></blockquote><br /> In principle, no, so long as the child has a handle to the
parentprocess that has<br /> the appropriate permissions.  Given that these processes have a parent/child<br />
relationshipthat shouldn't be too hard to arrange.<br /><blockquote
cite="mid:CA+TgmoZ2EL2zdt=e4FONQPGjjn4Y2N=-cu7q+cS+vWRnDgnR+Q@mail.gmail.com"type="cite"><div class="moz-text-plain"
graphical-quote="true"lang="x-western" style="font-family: -moz-fixed; font-size: 14px;" wrap="true"><pre wrap="">, or
canthe child just throw it over the
 
wall to the parent and let it rot until the postmaster finally exits?</pre></div></blockquote> Yes.  Though it might be
agood idea to record the handle somewhere (perhaps<br /> in a table) so that any potential issues from an insane system
spammingthe postmaster<br /> with handles are apparent.<br /><br /> I'm intrigued - how are the handles shared between
childrenthat are peers<br /> in the current scheme?  Some handle transfer must already be in place.<br /><br /> Could
youshare the handles to an immortal worker if you want to reduce any<br /> potential impact on the postmaster?<br
/><blockquotecite="mid:CA+TgmoZ2EL2zdt=e4FONQPGjjn4Y2N=-cu7q+cS+vWRnDgnR+Q@mail.gmail.com" type="cite"><div
class="moz-text-plain"graphical-quote="true" lang="x-western" style="font-family: -moz-fixed; font-size: 14px;"
wrap="true"><prewrap="">
 
The latter would be nicer for our purposes, perhaps, as running more
code from within the postmaster is risky for us.  If a regular backend
process dies, the postmaster will restart everything and the database
will come back on line, but if the postmaster itself dies, we're hard
down.

<div class="moz-txt-sig">-- 
Robert Haas
EnterpriseDB: <a class="moz-txt-link-freetext" href="http://www.enterprisedb.com"
moz-do-not-send="true">http://www.enterprisedb.com</a>
The Enterprise PostgreSQL Company
</div></pre></div></blockquote><br />