Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL

On 05/01/2014 18:02, Robert Haas wrote:
> On Sun, Jan 5, 2014 at 12:34 PM, james<james(at)mansionfamily(dot)plus(dot)com> wrote:
>> >On 05/01/2014 16:50, Robert Haas wrote:
>> >
>> > But on Windows, segments are*automatically*
>> >destroyed*by the operating system* when the last process unmaps them,
>> >so it's not quite so clear to me how we can allow it there. The main
>> >shared memory segment is no problem because the postmaster always has
>> >it mapped, even if no one else does, but that doesn't help for dynamic
>> >shared memory segments.
>> >
>> >Surely you just need to DuplicateHandle into the parent process? If you
>> >want to (tidily) dispose of it at some time, then you'll need to tell the
>> >postmaster that you have done so and what the handle is in its process,
>> >but if you just want it to stick around, then you can just pass it up.
> Uh, I don't know, maybe? Does the postmaster have to do something to
> receive the duplicated handle

In principle, no, so long as the child has a handle to the parent
process that has
the appropriate permissions. Given that these processes have a parent/child
relationship that shouldn't be too hard to arrange.
> , or can the child just throw it over the
> wall to the parent and let it rot until the postmaster finally exits?
Yes. Though it might be a good idea to record the handle somewhere (perhaps
in a table) so that any potential issues from an insane system spamming
the postmaster
with handles are apparent.

I'm intrigued - how are the handles shared between children that are peers
in the current scheme? Some handle transfer must already be in place.

Could you share the handles to an immortal worker if you want to reduce any
potential impact on the postmaster?
> 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.
>
> -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The
> Enterprise PostgreSQL Company