Re: Estimating total amount of shared memory required by postmaster

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

In response to

Responses

Browse pgsql-hackers by date

  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