On Jun 2, 2011, at 10:49 PM, Tom Lane wrote:
> Alexey Klyukin <alexk@commandprompt.com> writes:
>> We've recently come across the task of estimating the size of shared memory
>> required for PostgreSQL to start.
>
>> ...
>
>> - Try to actually allocate the shared memory in a way postmaster does this
>> nowadays, if the process fails - analyze the error code to check whether the
>> failure is due to the shmmax or shmmall limits being too low. This would
>> need to be run as a separate process (not postmaster's child) to avoid
>> messing with the postmaster's own shared memory, which means that this would
>> be hard to implement as a user-callable stored function.
>
> The results of such a test wouldn't be worth the electrons they're
> written on anyway: you're ignoring the likelihood that two instances of
> shared memory would overrun the kernel's SHMALL limit, when a single
> instance would be fine.
As Alvaro already pointed out, I'm not ignoring shmall. I think that:
- shmmax case is more frequent.
- there is a way to detect that shmall is a problem.
The other question is what to do when we detect that shmall is a problem.
I don't have a good answer for that ATM.
>
> Given that you can't do it in the context of a live installation, just
> trying to start the postmaster and seeing if it works (same as initdb
> does) seems as good as anything else.
In a context of configuration files validator a postmaster restart is definitely
not what we are looking for.
Alexey.
--
Command Prompt, Inc. http://www.CommandPrompt.com
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
