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: CA+TgmoajD9c_yRA1wP-vEFf10HwbnbRgpHZ3xp1Mcy3G1jOf=Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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
messages.

> 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
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment Content-Type Size
shmem-docs.patch application/octet-stream 10.6 KB

In response to

Responses

Browse pgsql-hackers by date

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