Address space reservation for shared memory

Currently the shared memory layout is designed to pack everything tight
together, leaving no space between mappings for resizing. Here is how it
looks like for one mapping in /proc/$PID/maps, /dev/zero represents the
anonymous shared memory we talk about:

    00400000-00490000         /path/bin/postgres
    ...
    012d9000-0133e000         [heap]
    7f443a800000-7f470a800000 /dev/zero (deleted)
    7f470a800000-7f471831d000 /usr/lib/locale/locale-archive
    7f4718400000-7f4718401000 /usr/lib64/libstdc++.so.6.0.34
    ...

Make the layout more dynamic via splitting every shared memory segment
into two parts:

* An anonymous file, which actually contains shared memory content. Such
  an anonymous file is created via memfd_create, it lives in memory,
  behaves like a regular file and semantically equivalent to an
  anonymous memory allocated via mmap with MAP_ANONYMOUS.

* A reservation mapping, which size is much larger than required shared
  segment size. This mapping is created with flags PROT_NONE (which
  makes sure the reserved space is not used), and MAP_NORESERVE (to not
  count the reserved space against memory limits). The anonymous file is
  mapped into this reservation mapping.

The resulting layout looks like this:

    00400000-00490000         /path/bin/postgres
    ...
    3f526000-3f590000 rw-p 		[heap]
    7fbd827fe000-7fbd8bdde000 rw-s 	/memfd:main (deleted) -- anon file
    7fbd8bdde000-7fbe82800000 ---s 	/memfd:main (deleted) -- reservation
    7fbe82800000-7fbe90670000 r--p 	/usr/lib/locale/locale-archive
    7fbe90800000-7fbe90941000 r-xp 	/usr/lib64/libstdc++.so.6.0.34

To resize a shared memory segment in this layout it's possible to use ftruncate
on the anonymous file, adjusting access permissions on the reserved space as
needed.

This approach also do not impact the actual memory usage as reported by
the kernel. Here is the output of /proc/$PID/status for the master
version with shared_buffers = 128 MB:

    // Peak virtual memory size, which is described as total pages
    // mapped in mm_struct. It corresponds to the mapped reserved space
    // and is the only number that grows with it.
    VmPeak:          2043192 kB
    // Size of memory portions. It contains RssAnon + RssFile + RssShmem
    VmRSS:             22908 kB
    // Size of resident anonymous memory
    RssAnon:             768 kB
    // Size of resident file mappings
    RssFile:           10364 kB
    // Size of resident shmem memory (includes SysV shm, mapping of tmpfs and
    // shared anonymous mappings)
    RssShmem:          11776 kB

Here is the same for the patch when reserving 20GB of space:

    VmPeak:         21255824 kB
    VmRSS:             25020 kB
    RssAnon:             768 kB
    RssFile:           10812 kB
    RssShmem:          13440 kB

Cgroup v2 doesn't have any problems with that as well. To verify a new cgroup
was created with the memory limit 256 MB, then PostgreSQL was launched withing
this cgroup with shared_buffers = 128 MB:

    $ cd /sys/fs/cgroup
    $ mkdir postgres
    $ cd postres
    $ echo 268435456 > memory.max

    $ echo $MASTER_PID_SHELL > cgroup.procs
    # postgres from the master branch has being successfully launched
    #  from that shell
    $ cat memory.current
    17465344 (~16.6 MB)
    # stop postgres

    $ echo $PATCH_PID_SHELL > cgroup.procs
    # postgres from the patch has being successfully launched from that shell
    $ cat memory.current
    20770816 (~19.8 MB)

To control the amount of space reserved a new GUC max_available_memory
is introduced. Ideally it should be based on the maximum available
memory, hense the name.

There are also few unrelated advantages of using anon files:

* We've got a file descriptor, which could be used for regular file
  operations (modification, truncation, you name it).

* The file could be given a name, which improves readability when it
  comes to process maps.

* By default, Linux will not add file-backed shared mappings into a core dump,
  making it more convenient to work with them in PostgreSQL: no more huge dumps
  to process.

The downside is that memfd_create is Linux specific.

Author: erthalion

src/backend/port/sysv_shmem.c

@@ -627,7 +627,7 @@ pgwin32_ReserveSharedMemoryRegion(HANDLE hChild)
  * use GetLargePageMinimum() instead.
  */
 void
-GetHugePageSize(Size *hugepagesize, int *mmap_flags)
+GetHugePageSize(Size *hugepagesize, int *mmap_flags, int *memfd_flags)
 {
 	if (hugepagesize)
 		*hugepagesize = 0;

src/backend/port/win32_shmem.c

@@ -206,6 +206,9 @@ CreateSharedMemoryAndSemaphores(void)
 
 	Assert(!IsUnderPostmaster);
 
+	/* Decide if we use huge pages or regular size pages */
+	PrepareHugePages();
+
 	for(int segment = 0; segment < ANON_MAPPINGS; segment++)
 	{
 		/* Compute the size of the shared-memory block */
@@ -377,7 +380,7 @@ InitializeShmemGUCs(void)
 	/*
 	 * Calculate the number of huge pages required.
 	 */
-	GetHugePageSize(&hp_size, NULL);
+	GetHugePageSize(&hp_size, NULL, NULL);
 	if (hp_size != 0)
 	{
 		Size		hp_required;

src/backend/storage/ipc/ipci.c

@@ -815,7 +815,7 @@ pg_get_shmem_pagesize(void)
 	Assert(huge_pages_status != HUGE_PAGES_UNKNOWN);
 
 	if (huge_pages_status == HUGE_PAGES_ON)
-		GetHugePageSize(&os_page_size, NULL);
+		GetHugePageSize(&os_page_size, NULL, NULL);
 
 	return os_page_size;
 }

src/backend/storage/ipc/shmem.c

@@ -140,6 +140,7 @@ int			max_parallel_maintenance_workers = 2;
  * register background workers.
  */
 int			NBuffers = 16384;
+int			MaxAvailableMemory = 524288;
 int			MaxConnections = 100;
 int			max_worker_processes = 8;
 int			max_parallel_workers = 8;

src/backend/utils/init/globals.c

@@ -1107,6 +1107,18 @@
   max => 'INT_MAX / 2',
 },
 
+# TODO: should this be PGC_POSTMASTER?
+{ name => "max_available_memory", type => 'int', context => 'PGC_SIGHUP', group => 'RESOURCES_MEM',
+  short_desc => 'Sets the upper limit for the shared_buffers value.',
+  long_desc => 'Shared memory could be resized at runtime, this parameters sets the upper limit for it, beyond which resizing would not be supported. Normally this value would be the same as the total available memory.',
+  flags => 'GUC_UNIT_BLOCKS',
+  variable => 'MaxAvailableMemory',
+  boot_val => '524288',
+  min => '16',
+  max => 'INT_MAX / 2',
+},
+
+
 { name => 'vacuum_buffer_usage_limit', type => 'int', context => 'PGC_USERSET', group => 'RESOURCES_MEM',
   short_desc => 'Sets the buffer pool size for VACUUM, ANALYZE, and autovacuum.',
   flags => 'GUC_UNIT_KB',

src/backend/utils/misc/guc_parameters.dat

@@ -173,6 +173,7 @@ extern PGDLLIMPORT char *DataDir;
 extern PGDLLIMPORT int data_directory_mode;
 
 extern PGDLLIMPORT int NBuffers;
+extern PGDLLIMPORT int MaxAvailableMemory;
 extern PGDLLIMPORT int MaxBackends;
 extern PGDLLIMPORT int MaxConnections;
 extern PGDLLIMPORT int max_worker_processes;

src/include/miscadmin.h

@@ -38,7 +38,7 @@
 #define MAP_NOSYNC			0
 #endif
 
-#define PG_MMAP_FLAGS			(MAP_SHARED|MAP_ANONYMOUS|MAP_HASSEMAPHORE)
+#define PG_MMAP_FLAGS			(MAP_SHARED|MAP_HASSEMAPHORE)
 
 /* Some really old systems don't define MAP_FAILED. */
 #ifndef MAP_FAILED

src/include/portability/mem.h

@@ -61,6 +61,7 @@ extern PGDLLIMPORT int shared_memory_type;
 extern PGDLLIMPORT int huge_pages;
 extern PGDLLIMPORT int huge_page_size;
 extern PGDLLIMPORT int huge_pages_status;
+extern PGDLLIMPORT int MaxAvailableMemory;
 
 /* Possible values for huge_pages and huge_pages_status */
 typedef enum
@@ -104,7 +105,9 @@ extern PGShmemHeader *PGSharedMemoryCreate(Size size,
 										   PGShmemHeader **shim);
 extern bool PGSharedMemoryIsInUse(unsigned long id1, unsigned long id2);
 extern void PGSharedMemoryDetach(void);
-extern void GetHugePageSize(Size *hugepagesize, int *mmap_flags);
+extern void GetHugePageSize(Size *hugepagesize, int *mmap_flags,
+							int *memfd_flags);
+void PrepareHugePages(void);
 
 /* The main segment, contains everything except buffer blocks and related data. */
 #define MAIN_SHMEM_SEGMENT 0