Skip site navigation (1) Skip section navigation (2)

Re: Shared memory and memory context question

From: Doug McNaught <doug(at)mcnaught(dot)org>
To: richard(dot)hills(at)balliol(dot)oxford(dot)ac(dot)uk
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Shared memory and memory context question
Date: 2006-02-05 14:16:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
richard(at)playford(dot)net writes:

> 1. Change memory context to TopMemoryContext and palloc everything there. 
> (However, I believe this still isn't shared between processes?)


> 2. Use the shmem functions in src/backend/storage/ipc/shmem.c to create a 
> chunk of shared memory and use this (Although I would like to avoid writing 
> my own memory manager to carve up the space).
> 3. Somehow create shared memory using the shmem functions, and set a memory 
> context to live *inside* this shared memory, which my trigger functions can 
> then switch to. Then use palloc() and pfree() without worrying..

You'd have to do one of the above, but #2 is probably out because all
shared memory is allocated to various purposes at startup and there is
none free at runtime (as I understand it).

For #3, how do you plan to have a memory context shared by multiple
backends with no synchronization?  If two backends try to do
allocation or deallocation at the same time you will get corruption,
as I don't think palloc() and pfree() do any locking (they currently
never allocate from shared memory).

You should probably think very carefully about whether you can get
along without using additional shared memory, because it's not that
easy to do.


In response to

pgsql-hackers by date

Next:From: Richard HillsDate: 2006-02-05 14:31:23
Subject: Re: Shared memory and memory context question
Previous:From: Magnus HaganderDate: 2006-02-05 14:15:58
Subject: Re: [PATCHES] Fix for running from admin account on win32

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group