Re: Posix Shared Mem patch
От | Robert Haas |
---|---|
Тема | Re: Posix Shared Mem patch |
Дата | |
Msg-id | CA+TgmoajD9c_yRA1wP-vEFf10HwbnbRgpHZ3xp1Mcy3G1jOf=Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Posix Shared Mem patch (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Posix Shared Mem patch
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: