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