前言：
一个很偶然的出现的问题，因为我需要验证备份文件是否正确，因此，我在一台已启动了一个数据库实例的服务器上，依据全备的数据库文件在启动一个实例，当然，在此之前，已经修改了备份文件内的配置文件的端口为5444，以防止端口占用，造成第二个数据库实例无法启动。
很不幸的，不出意外的出意外了，启动报错如下：
postgres@digoal-> FATAL: XX000: could not map anonymous shared memory: Cannot allocate memory
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 3322716160 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
LOCATION: CreateAnonymousSegment, pg_shmem.c:398一，
问题解析：
虽然这个报错里的每一个单词我都认识，但很可惜，它们合在一起的时候我还是陷入了迷茫，我发现我并不能准确的理解这个报错。
OK，但报错里的一些关键字很显然能给我提供一些信息，例如，
shared memory: Cannot allocate memory那么，这个报错提示我们是一个关于内存方面的错误的设置，postgresql里关于内存的设置有如下：
#shared_memory_type = mmap # the default is the first option
# supported by the operating system:
# mmap
# sysv
# windows
# (change requires restart)
dynamic_shared_memory_type = posix # the default is the first option
但是，第一个数据库是可以正常启动的，因为第一个数据库就是使用的这样的默认配置，因此，可以排除是postgresql的配置文件内的内存设置是有问题的。
如果说postgresql配置的内存选项有问题，这个从逻辑上是说不通的
检查服务器的内存，可以看到内存剩余的也是比较充裕的。
OK，那么，关于内存的设置只有一个内核优化的部分了
其中内核优化部分，关联内存的选项有一项引起了我的注意：
vm.overcommit_memory=2二，
关于vm.overcommit_memory
OK，之前设置的覆盖内存值是2，表示谨慎状态，以保持系统的问题，那么，1的值是宽松状态，表示内存全部用完，不做任何限制，0则是警告状态，能不能正确运行程序内核不参与，但如果内存不够，它将会报警。
那很明显，vm.overcommit_memory的值是2的时候，内存策略限制有点严重，经free命令查看，其实内存是够的，因此，vm.overcommit_memory的值修改为1即可解决以上的报错，第二个数据库就可以正常运行了
具体操作是编辑 /etc/sysctl.conf 文件，增加vm.overcommit_memory=1 这个选项，如果没有此项的话，如果vm.overcommit_memory的值不是1，修改成1即可。
sysctl -p 激活内核优化选项，完美运行两个postgresql实例。