where EXEC_BACKEND is defined
I noticed that when you want to define EXEC_BACKEND, perhaps to do some
non-Windows testing of that option, it's not clear how to do that. I
would have expected it in pg_config_manual.h, but it's actually in
configure.in and in MSBuildProject.pm. So if you want to define it
yourself, you kind of have to make up your own way to do it.
I don't see why this should be like that. I propose the attached patch
to move the thing to pg_config_manual.h.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
0001-Define-EXEC_BACKEND-in-pg_config_manual.h.patchtext/plain; charset=UTF-8; name=0001-Define-EXEC_BACKEND-in-pg_config_manual.h.patch; x-mac-creator=0; x-mac-type=0Download
From c7d574d3b9f363cc44daf45c543ab4addfa25afd Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Thu, 19 Mar 2020 16:32:02 +0100
Subject: [PATCH] Define EXEC_BACKEND in pg_config_manual.h
It was for unclear reasons defined in a separate location, which makes
it more cumbersome to override for testing, and it also did not have
any prominent documentation. Move to pg_config_manual.h, where
similar things are already collected.
---
configure | 2 +-
configure.in | 2 +-
src/include/pg_config_manual.h | 13 +++++++++++++
src/tools/msvc/MSBuildProject.pm | 2 +-
4 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/configure b/configure
index a7cf71b3f1..899116517c 100755
--- a/configure
+++ b/configure
@@ -6906,7 +6906,7 @@ fi
# We already have this in Makefile.win32, but configure needs it too
if test "$PORTNAME" = "win32"; then
- CPPFLAGS="$CPPFLAGS -I$srcdir/src/include/port/win32 -DEXEC_BACKEND"
+ CPPFLAGS="$CPPFLAGS -I$srcdir/src/include/port/win32"
fi
# Now that we're done automatically adding stuff to C[XX]FLAGS, put back the
diff --git a/configure.in b/configure.in
index d36a7e94b3..ecdf172396 100644
--- a/configure.in
+++ b/configure.in
@@ -600,7 +600,7 @@ fi
# We already have this in Makefile.win32, but configure needs it too
if test "$PORTNAME" = "win32"; then
- CPPFLAGS="$CPPFLAGS -I$srcdir/src/include/port/win32 -DEXEC_BACKEND"
+ CPPFLAGS="$CPPFLAGS -I$srcdir/src/include/port/win32"
fi
# Now that we're done automatically adding stuff to C[XX]FLAGS, put back the
diff --git a/src/include/pg_config_manual.h b/src/include/pg_config_manual.h
index d74a8dd808..b7410ff51e 100644
--- a/src/include/pg_config_manual.h
+++ b/src/include/pg_config_manual.h
@@ -122,6 +122,19 @@
*/
#define ALIGNOF_BUFFER 32
+/*
+ * If EXEC_BACKEND is defined, the postmaster uses an alternative method for
+ * starting subprocesses: Instead of simply using fork(), as is standard on
+ * Unix platforms, it uses fork()+exec() or something equivalent on Windows,
+ * as well as lots of extra code to bring the required global state to those
+ * new processes. This must be enabled on Windows (because there is no
+ * fork()). On other platforms, it's only useful for verifying those
+ * otherwise Windows-specific code paths.
+ */
+#if defined(WIN32) && !defined(__CYGWIN__)
+#define EXEC_BACKEND
+#endif
+
/*
* Disable UNIX sockets for certain operating systems.
*/
diff --git a/src/tools/msvc/MSBuildProject.pm b/src/tools/msvc/MSBuildProject.pm
index 823357c023..ebb169e201 100644
--- a/src/tools/msvc/MSBuildProject.pm
+++ b/src/tools/msvc/MSBuildProject.pm
@@ -320,7 +320,7 @@ sub WriteItemDefinitionGroup
<ClCompile>
<Optimization>$p->{opt}</Optimization>
<AdditionalIncludeDirectories>$self->{prefixincludes}src/include;src/include/port/win32;src/include/port/win32_msvc;$includes\%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
- <PreprocessorDefinitions>WIN32;_WINDOWS;__WINDOWS__;__WIN32__;EXEC_BACKEND;WIN32_STACK_RLIMIT=4194304;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE$self->{defines}$p->{defs}\%(PreprocessorDefinitions)</PreprocessorDefinitions>
+ <PreprocessorDefinitions>WIN32;_WINDOWS;__WINDOWS__;__WIN32__;WIN32_STACK_RLIMIT=4194304;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE$self->{defines}$p->{defs}\%(PreprocessorDefinitions)</PreprocessorDefinitions>
<StringPooling>$p->{strpool}</StringPooling>
<RuntimeLibrary>$p->{runtime}</RuntimeLibrary>
<DisableSpecificWarnings>$self->{disablewarnings};\%(DisableSpecificWarnings)</DisableSpecificWarnings>
--
2.25.0
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
I noticed that when you want to define EXEC_BACKEND, perhaps to do some
non-Windows testing of that option, it's not clear how to do that. I
would have expected it in pg_config_manual.h, but it's actually in
configure.in and in MSBuildProject.pm. So if you want to define it
yourself, you kind of have to make up your own way to do it.
Yeah. Personally, I tend to add the #define to pg_config.h
manually after running configure; I find this convenient because
the effects automatically go away at "make distclean", and I
don't have to remember to undo anything.
I don't see why this should be like that. I propose the attached patch
to move the thing to pg_config_manual.h.
I wouldn't use the option of editing pg_config_manual.h myself, because
of the need to undo it + risk of forgetting and committing that as part
of a patch. Still, this patch doesn't get in the way of continuing to
set it in pg_config.h, and it does offer a place to document the thing
which is a good idea as you say. So no objection here.
One small point is that I believe the existing code has the effect of
"#define EXEC_BACKEND 1" not just "#define EXEC_BACKEND". I don't
think this matters to anyplace in the core code, but it's conceivable
that somebody has extension code written to assume the former.
Nonetheless, I'm +1 for re-standardizing on the latter, because it's
a couple less keystrokes when inserting a manual definition ;-).
Might be worth mentioning in the commit log entry though.
regards, tom lane
On 2020-03-20 17:36, Tom Lane wrote:
One small point is that I believe the existing code has the effect of
"#define EXEC_BACKEND 1" not just "#define EXEC_BACKEND". I don't
think this matters to anyplace in the core code, but it's conceivable
that somebody has extension code written to assume the former.
Nonetheless, I'm +1 for re-standardizing on the latter, because it's
a couple less keystrokes when inserting a manual definition ;-).
Might be worth mentioning in the commit log entry though.
Ok, done that way.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services