On Thu, Jun 28, 2012 at 11:26 AM, Robert Haas <robertmhaas@gmail.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