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

From Robert Haas
Subject Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL
Date
Msg-id CA+TgmoZ8da3rCqA_uO0-W9G-R3Pab+AgF5mBJQFxgxx+CA5KFw@mail.gmail.com
Whole thread Raw
In response to Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL  (knizhnik <knizhnik@garret.ru>)
List pgsql-hackers
On Sun, Jan 5, 2014 at 1:28 PM, knizhnik <knizhnik@garret.ru> wrote:
> From my point of view it is not a big problem that it is not possible to
> place LWLock in DSM.
> I can allocate LWLocks in standard way - using RequestAddinLWLocks and use
> them for synchronization.

Sure, well, that works fine if you're being loaded from
shared_preload_libraries.  If you want to be able to load the
extension after startup time, though, it's no good.

> And what I still do not completely understand - how DSM enforces that
> segment created by one PosatgreSQL process will be mapped to the same
> virtual memory address in all other PostgreSQL processes.

It doesn't.  One process calls dsm_create() to create a shared memory
segment.  Other processes call dsm_attach() to attach it.  There's no
guarantee that they'll map it at the same address; they'll just map it
somewhere.

> Or may be DSM doesn't guarantee than DSM segment is mapped to the same
> address in all processes?
> In this case it significantly complicates DSM usage: it will not be possible
> to use direct pointers.

Yeah, that's where we're at.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] Store Extension Options
Next
From: Robert Haas
Date:
Subject: Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL