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.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
