Re: dynamically allocating chunks from shared memory

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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 17:47:09
Message-ID: 1281376029.2142.1228.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2010-08-09 at 11:41 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > So imagine that thread-or-process A allocates allocates a new chunk of
> > memory and then writes a pointer to the new chunk in a previously
> > allocated section of memory. Thread-or-process B then follows the
> > pointer. In a threaded model, this is guaranteed to be safe. In a
> > process model, it's not: A might have enlarged the shared memory
> > mapping while B has not yet done so. So I think in our model any sort
> > of change to the shared memory segment is going to require extremely
> > careful gymnastics, and be pretty expensive.
>
> ... and on some platforms, it'll be flat out impossible. We looked at
> this years ago and concluded that changing the size of the shmem segment
> after postmaster start was impractical from a portability standpoint.
> I have not seen anything to change that conclusion.

As caches get larger, downtime gets longer. Downtime of more than a few
minutes per year is enough to blow claims of high availability.

At some point, this project will need to face this particular hurdle. We
may need to balance utility for the majority against portability for the
minority.

We should be laying out an architectural roadmap, not just saying no. We
can make multi-year plans if we wish to.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-08-09 17:50:28 Re: Surprising dead_tuple_count from pgstattuple
Previous Message Daniel Oliveira 2010-08-09 17:14:54 Re: Universal B-tree