This is for the benefit of running postgres under the rr
debugger. When using rr signal handlers running while a syscall is
active use an alternative stack. As e.g. bgworkers are started from
within signal handlers, the forked backend then has a different stack
base than postmaster. Previously that subsequently lead to those
processes triggering spurious "stack depth limit exceeded" errors.
Discussion: https://postgr.es/m/
20200327182217.ubrrl32lyfhxfwk5@alap3.anarazel.de
index 73d278f3b2ccecb4c826eb049b1583cbaa9cc6fd..0578e92ba9c416d74693753e6083886db3227566 100644 (file)
/* Close the postmaster's sockets (as soon as we know them) */
ClosePostmasterPorts(strcmp(argv[1], "--forklog") == 0);
- /*
- * Set reference point for stack-depth checking
- */
- set_stack_base();
-
/*
* Set up memory area for GSS information. Mirrors the code in ConnCreate
* for the non-exec case.
index a7b7b12249d7551b42e5b233068403044c27bec9..6fe25c023a4e2da852cac6d4e81d85148e8f0dac 100644 (file)
{
IsUnderPostmaster = true; /* we are a postmaster subprocess now */
+ /*
+ * Set reference point for stack-depth checking. We re-do that even in the
+ * !EXEC_BACKEND case, because there are some edge cases where processes
+ * are started with an alternative stack (e.g. starting bgworkers when
+ * running postgres using the rr debugger, as bgworkers are launched from
+ * signal handlers).
+ */
+ set_stack_base();
+
InitProcessGlobals();
/*