On 02.06.2011 21:58, Alexey Klyukin wrote:
> Hello,
>
> We've recently come across the task of estimating the size of shared memory
> required for PostgreSQL to start. This comes from the problem of validating
> postgresql.conf files
> (http://archives.postgresql.org/pgsql-hackers/2011-03/msg01831.php), i.e.
> checking that the server will be able to start with new configuration options
> without actually performing the restart. Currently, I see a couple of ways
> to get the estimate:
>
> - Use the code from ipci.c to get the total size of the shared memory segment
> that Postmaster would be allocating with the given configuration options
> (shared_buffers, etc.). This would require getting the actual amount of
> available shared memory somehow, which is platform dependent and might not
> be very reliable. The other downside is that the code would need to be
> updated if the original estimates in ipci.c changes.
>
> - 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.
>
> I'm also looking for other ideas. Any suggestions?
There's a patch floating around to use POSIX shared memory, which
doesn't obey shmmax and shmmall limits:
http://archives.postgresql.org/message-id/D9EDACF7-53F1-4355-84F8-2E74CD19D22D@themactionfaction.com
That would allow us to fly under the radar and avoid the whole issue. If
you could review that patch, that would be great.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
