On Wed, Jun 9, 2021 at 9:15 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > > Magnus Hagander <magnus@xxxxxxxxxxxx> writes: > > I wonder how hard it would be to for example expose that through a > > commandline switch or tool. > > Just try to start the server and see if it complains. > For instance, with shared_buffers=10000000 I get > > 2021-06-09 15:08:56.821 EDT [1428121] FATAL: could not map anonymous shared memory: Cannot allocate memory > 2021-06-09 15:08:56.821 EDT [1428121] HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space, or huge pages. To reduce the request size (currently 83720568832 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections. > > Of course, if it *does* start, you can do the other thing. Well, I have to *stop* the existing one first, most likely, otherwise there won't be enough huge pages (or indeed memory) available. And if then doesn't start, you're looking at extended downtime. You can automate this to minimize it (set the value in the conf, stop old, start new, if new doesn't start then stop new, reconfigure, start old again), but it's *far* from friendly. This process works when you're setting up a brand new server with nobody using it. It doesn't work well, or at all, when you actually have active users on it.. > Admittedly, we could make that easier somehow; but if it took > 25 years for somebody to ask for this, I'm not sure it's > worth creating a feature to make it a shade easier. We haven't had huge page support for 25 years, "only" since 9.4 so about 7 years. And for every year that passes, huge pages become more interesting in that in general memory sizes increase so the payoff of using them is increased. Using huge pages *should* be a trivial improvement to set up. But it's in my experience complicated enough that many just skip it simply for that reason. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
