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

Re: Posix Shared Mem patch

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Posix Shared Mem patch
Date: 2012-07-03 13:57:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Jun 28, 2012 at 11:26 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Assuming things go well, there are a number of follow-on things that
> we need to do finish this up:
> 1. Update the documentation.  I skipped this for now, because I think
> that what we write there is going to be heavily dependent on how
> portable this turns out to be, which we don't know yet.  Also, it's
> not exactly clear to me what the documentation should say if this does
> turn out to work everywhere.  Much of section 17.4 will become
> irrelevant to most users, but I doubt we'd just want to remove it; it
> could still matter for people running EXEC_BACKEND or running many
> postmasters on the same machine or, of course, people running on
> platforms where this just doesn't work, if there are any.

Here's a patch that attempts to begin the work of adjusting the
documentation for this brave new world.  I am guessing that there may
be other places in the documentation that also require updating, and
this page probably needs more work, but it's a start.

> 2. Update the HINT messages when shared memory allocation fails.
> Maybe the new most-common-failure mode there will be too many
> postmasters running on the same machine?  We might need to wait for
> some field reports before adjusting this.

I think this is mostly a matter of removing the text that says "fix
this by reducing shme-related parameters" from the relevant hint

> 3. Consider adjusting the logic inside initdb.  If this works
> everywhere, the code for determining how to set shared_buffers should
> become pretty much irrelevant.  Even if it only works some places, we
> could add 64MB or 128MB or whatever to the list of values we probe, so
> that people won't get quite such a sucky configuration out of the box.
>  Of course there's no number here that will be good for everyone.

I posted a patch for this one last night.

Robert Haas
The Enterprise PostgreSQL Company

Attachment: shmem-docs.patch
Description: application/octet-stream (10.6 KB)

In response to


pgsql-hackers by date

Next:From: Jeff DavisDate: 2012-07-03 14:26:08
Subject: Re: SP-GiST for ranges based on 2d-mapping and quad-tree
Previous:From: Hans-Jürgen SchönigDate: 2012-07-03 13:30:44
Subject: "Bloom filter" for 9.2 ...

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