Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL - Mailing list pgsql-hackers
From | Amit Kapila |
---|---|
Subject | Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL |
Date | |
Msg-id | CAA4eK1JTa_iusGTHp=kmtWcg-Lqgszzvk8Ek9iu3td3Wm0_BTQ@mail.gmail.com Whole thread Raw |
In response to | Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL
Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL |
List | pgsql-hackers |
On Thu, Jan 9, 2014 at 12:21 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Jan 7, 2014 at 10:20 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> On Tue, Jan 7, 2014 at 2:46 AM, Robert Haas <robertmhaas@gmail.com> wrote: >>> >>> Well, right now we just reopen the same object from all of the >>> processes, which seems to work fine and doesn't require any of this >>> complexity. The only problem I don't know how to solve is how to make >>> a segment stick around for the whole postmaster lifetime. If >>> duplicating the handle into the postmaster without its knowledge gets >>> us there, it may be worth considering, but that doesn't seem like a >>> good reason to rework the rest of the existing mechanism. >> >> I think one has to try this to see if it works as per the need. If it's not >> urgent, I can try this early next week? > > Anything we want to get into 9.4 has to be submitted by next Tuesday, > but I don't know that we're going to get this into 9.4. Using DuplicateHandle(), we can make segment stick for Postmaster lifetime. I have used below test (used dsm_demo module) to verify: Session - 1 select dsm_demo_create('this message is from session-1');dsm_demo_create ----------------- 827121111 Session - 2 ----------------- select dsm_demo_read(827121111); dsm_demo_read ----------------------------this message is from session-1 (1 row) Session-1 \q -- till here it will work without DuplicateHandle as well Session -2 select dsm_demo_read(827121111); dsm_demo_read ----------------------------this message is from session-1 (1 row) Session -2 \q Session -3 select dsm_demo_read(827121111); dsm_demo_read ----------------------------this message is from session-1 (1 row) -- above shows that handle stays around. Note - Currently I have to bypass below code in dam_attach(), as it assumes segment will not stay if it's removed from control file. /* * If we didn't find the handle we're looking for in the control * segment, it probably means that everyone else who had it mapped, * including the original creator, died before we got to this point. * It's up to the caller to decide what to do about that. */ if (seg->control_slot == INVALID_CONTROL_SLOT) { dsm_detach(seg); return NULL; } Could you let me know what exactly you are expecting in patch, just a call to DuplicateHandle() after CreateFileMapping() or something else as well? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
pgsql-hackers by date: