Re: dynamically allocating chunks from shared memory

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Markus Wanner <markus(at)bluegap(dot)ch>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: dynamically allocating chunks from shared memory
Date: 2010-08-09 23:17:48
Message-ID: 16034.1281395868@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Aug 9, 2010 at 4:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Particular implementations might cope with such cases in useful ways, or
>> then again they might not.

> That doesn't seem like a big problem to me. I was assuming we'd need
> to remap when the size changed.

Well, as long as you can do that, sure. I'm concerned about what
happens if/when remapping fails (not at all unlikely in 32-bit address
spaces in particular). You mentioned that that would probably have to
be a PANIC condition, which I think I agree with; and that idea pretty
much kills any argument that this would be a good way to improve server
uptime.

Another issue is that if you're doing dynamic remapping you almost
certainly can't assume that the segment will appear at the same
addresses in every backend. We could live with that for shared buffers
without too much pain, but not so much for most other shared
datastructures.

> Also, I was assuming that we were
> going to use shms, not files.

It looked to me like the spec for mmap was the same either way.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-08-09 23:39:39 Re: security label support, part.2
Previous Message Simon Riggs 2010-08-09 23:00:45 Re: Surprising dead_tuple_count from pgstattuple