On Jun 2, 2011, at 10:49 PM, Tom Lane wrote: > Alexey Klyukin <al...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
