From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alexey Klyukin <alexk(at)commandprompt(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Estimating total amount of shared memory required by postmaster |
Date: | 2011-06-02 19:49:53 |
Message-ID: | 27565.1307044193@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alexey Klyukin <alexk(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-06-02 19:54:30 | Re: pgpool versus sequences |
Previous Message | Radosław Smogura | 2011-06-02 19:26:29 | Re: BLOB support |