On postgresql startup, I see this in the log files

2017-07-17 05:21:01.743 UTC > LOCATION: CreateAnonymousSegment, pg_shmem.c:484
2017-07-17 05:21:01.868 UTC > LOG: 00000: redirecting log output to logging collector process
2017-07-17 05:21:01.868 UTC > HINT: Future log output will appear in directory "pg_log".
2017-07-17 05:21:01.868 UTC > LOCATION: SysLogger_Start, syslogger.c:622
2017-07-21 05:46:01.680 UTC > DEBUG: 00000: logger shutting down
2017-07-21 05:46:01.680 UTC > LOCATION: SysLoggerMain, syslogger.c:490
2017-07-21 05:46:01.973 UTC > DEBUG: 00000: mmap(8264876032) with MAP_HUGETLB failed, huge pages disabled: Cannot allocate memory

I have never used huge pages - turning on huge_pages in postgres.conf does not help, I get different errors and the server will not start. I am unfamiliar with these settings.

Please help point me in the right direction to explore why these errors are occurring and what I should do about them - adjustments to memory settings, logging (it is set very high) vacuuming, or what?

What parts of the PostgreSQL manual are relevant?

Stack: postgresql 9.6 on aws ec2 generic linux

UPDATE: This post was originally written about things I noticed on installing a backup utility, and how that appeared to be causing errors, then I noticed a server without the utility is logging the same messages.

  • 1
    its a usual out of memory error.
    – Sahap Asci
    Sep 3, 2017 at 21:02
  • What are the differences in configuration between the server that you cloned and the server you are restoring to? You need to be sure at the very least to use the same postgresql.conf and sysctl.conf. Since your data directory looks like it's on a RHEL/CentOS variant, you could reload it with sysctl -p. Given your error messages, it looks like you need to change the kern.ipc.shmmax to be greater than the number of bytes listed in your second error message, as noted in the Managing Kernel Resources section of the docs.
    – Kassandry
    Sep 4, 2017 at 4:51
  • It turns out the MAP_HUGETLB errors are on the production server too - so it appears those are unrelated to barman. I am going to have to rewrite this post or delete it.
    – csdev
    Sep 4, 2017 at 17:17
  • 1
    This question is rewritten without mentioning barman or replication - I think it might just be memory misconfiguration, or logging is up too high or something - I will begin exploring the kernel memory resources section
    – csdev
    Sep 4, 2017 at 18:48
  • Which instance type are you using? What are the memory-related PostgreSQL settings? Is there any activity at the time of the problem, or is it really the startup? Sep 4, 2017 at 20:15

2 Answers 2


Met the same issue when deploying postgre-sql by postgres-operator (https://github.com/zalando/postgres-operator) in Kubernetes. The size of required shared memory usage by postgre-sql is based on shared_buffers and max_connections. While, the shared_buffers configured by patroni is calculated based on the size of physical memory in the host. In our case, the size of physical memory is huge, however the memory limit of the container of postgre-sql is configured much less than the size of physical memory in the host. As a result, postgre-sql tries to allocate 4GB memory however only 256MB is available, and then fail to start.

Specify shared_buffers with a reasonable value resolved the problem.


Own experience suggests that this is due to PostgreSQL running out-of-memory.

For instance, I ran into this error when attempting to bump max_connections up to a very high value (say, 2000) on a "small" server.

  • After migration from 2gbRAM to server having 8gbRAM I ran into the OPs issue. Changing max_connections from 6200 down to 200 did not solve the problem.
    – Grim
    Jan 6, 2020 at 12:32
  • Refer: postgresql.org/docs/9.6/kernel-resources.html. This might help you
    – sudalai
    Jan 6, 2020 at 14:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.