Fix crashes caused by stack size increase under high memory load

Each PostgreSQL backend starts with a predefined amount of stack and this stack
size can be increased if there is a need. However, stack size increase during
high memory load may cause unexpected crashes, because if there is not enough
memory for stack size increase, there is nothing to do for process apart from
crashing. An interesting thing is; the process would get OOM error instead of
crash, if the process had an explicit memory request (with palloc) for example.
However, in the case of stack size increase, there is no system call to get OOM
error, so the process simply crashes.

With this change, we are increasing the stack size explicitly by requesting extra
memory from the stack, so that, even if there is not memory, we can at least get
an OOM instead of a crash.

src/backend/distributed/shared_library_init.c

@@ -55,6 +55,7 @@
 #include "postmaster/postmaster.h"
 #include "optimizer/planner.h"
 #include "optimizer/paths.h"
+#include "tcop/tcopprot.h"
 #include "utils/guc.h"
 #include "utils/guc_tables.h"
 
@@ -65,6 +66,7 @@ static char *CitusVersion = CITUS_VERSION;
 
 void _PG_init(void);
 
+static void ResizeStackToMaximumDepth(void);
 static void multi_log_hook(ErrorData *edata);
 static void CreateRequiredDirectories(void);
 static void RegisterCitusConfigVariables(void);
@@ -169,6 +171,8 @@ _PG_init(void)
 								"shared_preload_libraries.")));
 	}
 
+	ResizeStackToMaximumDepth();
+
 	/*
 	 * Extend the database directory structure before continuing with
 	 * initialization - one of the later steps might require them to exist.
@@ -234,6 +238,35 @@ _PG_init(void)
 }
 
 
+/*
+ * Stack size increase during high memory load may cause unexpected crashes.
+ * With this alloca call, we are increasing stack size explicitly, so that if
+ * it is not possible to increase stack size, we will get an OOM error instead
+ * of a crash.
+ *
+ * This function is called on backend startup. The allocated memory will
+ * automatically be released at the end of the function's scope. However, we'd
+ * have already expanded the stack and it wouldn't shrink back. So, in a sense,
+ * per backend we're securing max_stack_depth kB's of memory on the stack upfront.
+ *
+ * Not all the backends require max_stack_depth kB's on the stack, so we might end
+ * up with unnecessary allocations. However, the default value is 2MB, which seems
+ * an acceptable trade-off. Also, allocating memory upfront may perform better
+ * under some circumstances.
+ */
+static void
+ResizeStackToMaximumDepth(void)
+{
+#ifndef WIN32
+	volatile char *stack_resizer = NULL;
+	long max_stack_depth_bytes = max_stack_depth * 1024L;
+
+	stack_resizer = alloca(max_stack_depth_bytes);
+	stack_resizer[max_stack_depth_bytes - 1] = 0;
+#endif
+}
+
+
 /*
  * multi_log_hook intercepts postgres log commands. We use this to override
  * postgres error messages when they're not specific enough for the users.