Dead code in ps_status.c
Hi,
Here's some archeology I did a while back, but was reminded to post
when I saw David's nearby performance improvements for ps_status.c.
* there are no systems with HAVE_PS_STRINGS (ancient BSD)
* setproctitle_fast() is in all live FreeBSD releases
* setproctitle() is in all other BSDs
* PostgreSQL can't run on GNU/Hurd apparently, for lack of shared
sempahores, so who would even know if that works?
* IRIX is rusting in peace
* there are no other NeXT-derived systems (NeXTSTEP and OPENSTEP are departed)
Therefore I think it is safe to drop the PS_USE_PS_STRING and
PS_USE_CHANGE_ARGV code branches, remove a bunch of outdated comments
and macro tests, and prune the defunct configure/meson probe.
I guess (defined(sun) && !defined(BSD)) || defined(__svr5__) could be
changed to just defined(sun) (surely there are no other living
SysV-derived systems, and I think non-BSD Sun probably meant "Solaris
but not SunOS"), but I don't know so I didn't touch that.
I think the history here is that the ancient BSD sendmail code
(conf.c) had all this stuff for BSD and SVR5 systems, but then its
setproctitle() function actually moved into the OS so that the
underlying PS_STRINGS stuff wouldn't have to be stable, and indeed it
was not.
Attachments:
0001-Remove-obsolete-code-from-ps_status.c.patchtext/x-patch; charset=US-ASCII; name=0001-Remove-obsolete-code-from-ps_status.c.patchDownload
From fdca29db1140aac55f9b07d63bf5cdc7555454da Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@gmail.com>
Date: Thu, 16 Feb 2023 15:48:50 +1300
Subject: [PATCH] Remove obsolete code from ps_status.c.
We can now remove various code, comments and configure/meson probes for
ancient BSD variants, GNU/Hurd, IRIX, NeXT.
---
configure | 35 -------------------
configure.ac | 13 -------
meson.build | 17 ---------
src/backend/utils/misc/ps_status.c | 55 +++++-------------------------
src/include/pg_config.h.in | 3 --
5 files changed, 9 insertions(+), 114 deletions(-)
diff --git a/configure b/configure
index 7bb829ddf4..e35769ea73 100755
--- a/configure
+++ b/configure
@@ -16278,41 +16278,6 @@ cat >>confdefs.h <<_ACEOF
_ACEOF
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for PS_STRINGS" >&5
-$as_echo_n "checking for PS_STRINGS... " >&6; }
-if ${pgac_cv_var_PS_STRINGS+:} false; then :
- $as_echo_n "(cached) " >&6
-else
- cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h. */
-#include <machine/vmparam.h>
-#include <sys/exec.h>
-
-int
-main ()
-{
-PS_STRINGS->ps_nargvstr = 1;
-PS_STRINGS->ps_argvstr = "foo";
- ;
- return 0;
-}
-_ACEOF
-if ac_fn_c_try_link "$LINENO"; then :
- pgac_cv_var_PS_STRINGS=yes
-else
- pgac_cv_var_PS_STRINGS=no
-fi
-rm -f core conftest.err conftest.$ac_objext \
- conftest$ac_exeext conftest.$ac_ext
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $pgac_cv_var_PS_STRINGS" >&5
-$as_echo "$pgac_cv_var_PS_STRINGS" >&6; }
-if test "$pgac_cv_var_PS_STRINGS" = yes ; then
-
-$as_echo "#define HAVE_PS_STRINGS 1" >>confdefs.h
-
-fi
-
ac_fn_c_check_func "$LINENO" "explicit_bzero" "ac_cv_func_explicit_bzero"
if test "x$ac_cv_func_explicit_bzero" = xyes; then :
$as_echo "#define HAVE_EXPLICIT_BZERO 1" >>confdefs.h
diff --git a/configure.ac b/configure.ac
index 137a40a942..af23c15cb2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1849,19 +1849,6 @@ AC_CHECK_DECLS([pwritev], [], [AC_LIBOBJ(pwritev)], [#include <sys/uio.h>])
# This is probably only present on macOS, but may as well check always
AC_CHECK_DECLS(F_FULLFSYNC, [], [], [#include <fcntl.h>])
-AC_CACHE_CHECK([for PS_STRINGS], [pgac_cv_var_PS_STRINGS],
-[AC_LINK_IFELSE([AC_LANG_PROGRAM(
-[#include <machine/vmparam.h>
-#include <sys/exec.h>
-],
-[PS_STRINGS->ps_nargvstr = 1;
-PS_STRINGS->ps_argvstr = "foo";])],
-[pgac_cv_var_PS_STRINGS=yes],
-[pgac_cv_var_PS_STRINGS=no])])
-if test "$pgac_cv_var_PS_STRINGS" = yes ; then
- AC_DEFINE([HAVE_PS_STRINGS], 1, [Define to 1 if the PS_STRINGS thing exists.])
-fi
-
AC_REPLACE_FUNCS(m4_normalize([
explicit_bzero
getopt
diff --git a/meson.build b/meson.build
index b5daed9f38..f534704452 100644
--- a/meson.build
+++ b/meson.build
@@ -2293,23 +2293,6 @@ endif
cdata.set('pg_restrict', '__restrict')
-if cc.links('''
-#include <machine/vmparam.h>
-#include <sys/exec.h>
-
-int main(void)
-{
- PS_STRINGS->ps_nargvstr = 1;
- PS_STRINGS->ps_argvstr = "foo";
-}
-''',
- name: 'PS_STRINGS', args: test_c_args)
- cdata.set('HAVE_PS_STRINGS', 1)
-else
- cdata.set('HAVE_PS_STRINGS', false)
-endif
-
-
# Most libraries are included only if they demonstrably provide a function we
# need, but libm is an exception: always include it, because there are too
# many compilers that play cute optimization games that will break probes for
diff --git a/src/backend/utils/misc/ps_status.c b/src/backend/utils/misc/ps_status.c
index 06bdc2afd1..d6a3389c29 100644
--- a/src/backend/utils/misc/ps_status.c
+++ b/src/backend/utils/misc/ps_status.c
@@ -15,10 +15,6 @@
#include "postgres.h"
#include <unistd.h>
-#ifdef HAVE_PS_STRINGS
-#include <machine/vmparam.h> /* for old BSD */
-#include <sys/exec.h>
-#endif
#if defined(__darwin__)
#include <crt_externs.h>
#endif
@@ -39,16 +35,10 @@ bool update_process_title = DEFAULT_UPDATE_PROCESS_TITLE;
*
* PS_USE_SETPROCTITLE_FAST
* use the function setproctitle_fast(const char *, ...)
- * (newer FreeBSD systems)
+ * (FreeBSD)
* PS_USE_SETPROCTITLE
* use the function setproctitle(const char *, ...)
- * (newer BSD systems)
- * PS_USE_PS_STRINGS
- * assign PS_STRINGS->ps_argvstr = "string"
- * (some BSD systems)
- * PS_USE_CHANGE_ARGV
- * assign argv[0] = "string"
- * (some other BSD systems)
+ * (other BSDs)
* PS_USE_CLOBBER_ARGV
* write over the argv and environment area
* (Linux and most SysV-like systems)
@@ -62,11 +52,7 @@ bool update_process_title = DEFAULT_UPDATE_PROCESS_TITLE;
#define PS_USE_SETPROCTITLE_FAST
#elif defined(HAVE_SETPROCTITLE)
#define PS_USE_SETPROCTITLE
-#elif defined(HAVE_PS_STRINGS)
-#define PS_USE_PS_STRINGS
-#elif (defined(BSD) || defined(__hurd__)) && !defined(__darwin__)
-#define PS_USE_CHANGE_ARGV
-#elif defined(__linux__) || defined(_AIX) || defined(__sgi) || (defined(sun) && !defined(BSD)) || defined(__svr5__) || defined(__darwin__)
+#elif defined(__linux__) || defined(_AIX) || (defined(sun) && !defined(BSD)) || defined(__svr5__) || defined(__darwin__)
#define PS_USE_CLOBBER_ARGV
#elif defined(WIN32)
#define PS_USE_WIN32
@@ -186,9 +172,6 @@ save_ps_display_args(int argc, char **argv)
new_environ[i] = NULL;
environ = new_environ;
}
-#endif /* PS_USE_CLOBBER_ARGV */
-
-#if defined(PS_USE_CHANGE_ARGV) || defined(PS_USE_CLOBBER_ARGV)
/*
* If we're going to change the original argv[] then make a copy for
@@ -226,15 +209,15 @@ save_ps_display_args(int argc, char **argv)
#if defined(__darwin__)
/*
- * macOS (and perhaps other NeXT-derived platforms?) has a static copy
- * of the argv pointer, which we may fix like so:
+ * macOS has a static copy of the argv pointer, which we may fix like
+ * so:
*/
*_NSGetArgv() = new_argv;
#endif
argv = new_argv;
}
-#endif /* PS_USE_CHANGE_ARGV or PS_USE_CLOBBER_ARGV */
+#endif /* PS_USE_CLOBBER_ARGV */
return argv;
}
@@ -271,25 +254,10 @@ init_ps_display(const char *fixed_part)
/* If ps_buffer is a pointer, it might still be null */
if (!ps_buffer)
return;
-#endif
-
- /*
- * Overwrite argv[] to point at appropriate space, if needed
- */
-#ifdef PS_USE_CHANGE_ARGV
- save_argv[0] = ps_buffer;
- save_argv[1] = NULL;
-#endif /* PS_USE_CHANGE_ARGV */
-
-#ifdef PS_USE_CLOBBER_ARGV
- {
- int i;
-
- /* make extra argv slots point at end_of_area (a NUL) */
- for (i = 1; i < save_argc; i++)
- save_argv[i] = ps_buffer + ps_buffer_size;
- }
+ /* make extra argv slots point at end_of_area (a NUL) */
+ for (int i = 1; i < save_argc; i++)
+ save_argv[i] = ps_buffer + ps_buffer_size;
#endif /* PS_USE_CLOBBER_ARGV */
/*
@@ -369,11 +337,6 @@ set_ps_display(const char *activity)
setproctitle_fast("%s", ps_buffer);
#endif
-#ifdef PS_USE_PS_STRINGS
- PS_STRINGS->ps_nargvstr = 1;
- PS_STRINGS->ps_argvstr = ps_buffer;
-#endif /* PS_USE_PS_STRINGS */
-
#ifdef PS_USE_CLOBBER_ARGV
/* pad unused memory; need only clobber remainder of old status string */
if (last_status_len > ps_buffer_cur_len)
diff --git a/src/include/pg_config.h.in b/src/include/pg_config.h.in
index 2490bf8ace..20c82f5979 100644
--- a/src/include/pg_config.h.in
+++ b/src/include/pg_config.h.in
@@ -334,9 +334,6 @@
/* Define to 1 if you have the `ppoll' function. */
#undef HAVE_PPOLL
-/* Define to 1 if the PS_STRINGS thing exists. */
-#undef HAVE_PS_STRINGS
-
/* Define if you have POSIX threads libraries and header files. */
#undef HAVE_PTHREAD
--
2.39.1
Thomas Munro <thomas.munro@gmail.com> writes:
Therefore I think it is safe to drop the PS_USE_PS_STRING and
PS_USE_CHANGE_ARGV code branches, remove a bunch of outdated comments
and macro tests, and prune the defunct configure/meson probe.
Seems reasonable. Patch passes an eyeball check.
I guess (defined(sun) && !defined(BSD)) || defined(__svr5__) could be
changed to just defined(sun) (surely there are no other living
SysV-derived systems, and I think non-BSD Sun probably meant "Solaris
but not SunOS"), but I don't know so I didn't touch that.
Hm, is "defined(sun)" true on any live systems at all?
regards, tom lane
On Thu, Feb 16, 2023 at 6:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Thomas Munro <thomas.munro@gmail.com> writes:
Therefore I think it is safe to drop the PS_USE_PS_STRING and
PS_USE_CHANGE_ARGV code branches, remove a bunch of outdated comments
and macro tests, and prune the defunct configure/meson probe.Seems reasonable. Patch passes an eyeball check.
Thanks for looking.
I guess (defined(sun) && !defined(BSD)) || defined(__svr5__) could be
changed to just defined(sun) (surely there are no other living
SysV-derived systems, and I think non-BSD Sun probably meant "Solaris
but not SunOS"), but I don't know so I didn't touch that.Hm, is "defined(sun)" true on any live systems at all?
My GCC compile farm account seems to have expired, or something, so I
couldn't check on wrasse's host (though whether wrasse is "live" is
debatable: Solaris 11.3 has reached EOL, it's just that the CPU is too
old to be upgraded, so it's not testing a real OS that anyone would
actually run PostgreSQL on). But from some googling[1]https://stackoverflow.com/questions/16618604/solaris-and-preprocessor-macros, I think
__sun, __sun__ and sun should all be defined.
Ohh, but __svr5__ should not be. Solaris boxes define __svr4__, I was
confused by the two fives. __svr5__ was SCO/Unixware, another dead
OS[1]https://stackoverflow.com/questions/16618604/solaris-and-preprocessor-macros, so I think we can just remove that one too. So, yeah, I think
we should replace (defined(sun) && !defined(BSD)) || defined(__svr5__)
with defined(__sun). (Hmph. We have all of __sun__, __sun and sun in
the tree.)
[1]: https://stackoverflow.com/questions/16618604/solaris-and-preprocessor-macros
[2]: https://en.wikipedia.org/wiki/UNIX_System_V#SVR5_/_UnixWare_7
Thomas Munro <thomas.munro@gmail.com> writes:
On Thu, Feb 16, 2023 at 6:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Hm, is "defined(sun)" true on any live systems at all?
My GCC compile farm account seems to have expired, or something, so I
couldn't check on wrasse's host (though whether wrasse is "live" is
debatable: Solaris 11.3 has reached EOL, it's just that the CPU is too
old to be upgraded, so it's not testing a real OS that anyone would
actually run PostgreSQL on). But from some googling[1], I think
__sun, __sun__ and sun should all be defined.
My account still works, and what I see on wrasse's host is
tgl@gcc-solaris11:~$ gcc -x c /dev/null -dM -E | grep -i svr
#define __SVR4 1
#define __svr4__ 1
tgl@gcc-solaris11:~$ gcc -x c /dev/null -dM -E | grep -i sun
#define __sun 1
#define sun 1
#define __sun__ 1
I don't know a way to get the list of predefined macros out of the
compiler wrasse is actually using (/opt/developerstudio12.6/bin/cc),
but doing some experiments with #ifdef confirmed that it defines
__sun, __sun__, and __svr4__, but not __svr5__.
regards, tom lane
On Fri, Feb 17, 2023 at 3:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
My account still works, and what I see on wrasse's host is
tgl@gcc-solaris11:~$ gcc -x c /dev/null -dM -E | grep -i svr
#define __SVR4 1
#define __svr4__ 1
tgl@gcc-solaris11:~$ gcc -x c /dev/null -dM -E | grep -i sun
#define __sun 1
#define sun 1
#define __sun__ 1I don't know a way to get the list of predefined macros out of the
compiler wrasse is actually using (/opt/developerstudio12.6/bin/cc),
but doing some experiments with #ifdef confirmed that it defines
__sun, __sun__, and __svr4__, but not __svr5__.
Thanks. I went with __sun, because a random man page google found me
for Sun "cc" mentioned that but not __sun__. Pushed.
http://www.polarhome.com/service/man/?qf=cc&tf=2&of=Solaris&sf=1
On Fri, Feb 17, 2023 at 3:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Thomas Munro <thomas.munro@gmail.com> writes:
On Thu, Feb 16, 2023 at 6:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
My GCC compile farm account seems to have expired, or something, so I
couldn't check on wrasse's host (though whether wrasse is "live" is
debatable: Solaris 11.3 has reached EOL, it's just that the CPU is too
old to be upgraded, so it's not testing a real OS that anyone would
actually run PostgreSQL on). ...
My account still works, and what I see on wrasse's host is
Just in case it helps someone else who finds themselves locked out of
that, I noticed that I can still connect from my machine with OpenSSH
8.8p1, but not from another dev box which was upgraded to OpenSSH
9.2p1. For reasons I didn't look into, the latter doesn't like
exchanging 1s and 0s with "Sun_SSH_2.4" (something Oracle has
apparently now abandoned in favour of stock OpenSSH, but that machine
is stuck in time).
Hi,
On 2023-03-11 16:59:46 +1300, Thomas Munro wrote:
On Fri, Feb 17, 2023 at 3:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Thomas Munro <thomas.munro@gmail.com> writes:
On Thu, Feb 16, 2023 at 6:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
My GCC compile farm account seems to have expired, or something, so I
couldn't check on wrasse's host (though whether wrasse is "live" is
debatable: Solaris 11.3 has reached EOL, it's just that the CPU is too
old to be upgraded, so it's not testing a real OS that anyone would
actually run PostgreSQL on). ...My account still works, and what I see on wrasse's host is
Just in case it helps someone else who finds themselves locked out of
that, I noticed that I can still connect from my machine with OpenSSH
8.8p1, but not from another dev box which was upgraded to OpenSSH
9.2p1. For reasons I didn't look into, the latter doesn't like
exchanging 1s and 0s with "Sun_SSH_2.4" (something Oracle has
apparently now abandoned in favour of stock OpenSSH, but that machine
is stuck in time).
It's the key types supported by the old ssh. I have the following in my
~/.ssh/config to work around that:
Host gcc210.fsffrance.org
PubkeyAcceptedKeyTypes +ssh-rsa
KexAlgorithms +diffie-hellman-group1-sha1
Host gcc211.fsffrance.org
PubkeyAcceptedKeyTypes +ssh-rsa
Greetings,
Andres Freund
Hi,
On Thu, Feb 16, 2023 at 04:52:33PM +1300, Thomas Munro wrote:
Therefore I think it is safe to drop the PS_USE_PS_STRING and
PS_USE_CHANGE_ARGV code branches, remove a bunch of outdated comments
and macro tests, and prune the defunct configure/meson probe.
I noticed Postgres no longer updates the process title on the Hurd, this
is because this was removed along other legacy platforms in this commit
as it was using PS_USE_PS_STRING.
Just doing the same as what Linux does (PS_USE_CLOBBER_ARGV) works, so
I've added the __GNU__ definition to it. Process handling on Linux and
the Hurd are different enough that just changing it to __GLIBC__ would
not be advisable IMV.
Patch attached.
Michael
Attachments:
0001-Define-PS_USE_CLOBBER_ARGV-on-GNU-Hurd-to-re-enable-.patchtext/x-diff; charset=us-asciiDownload
From c6e967c3f389b96d74c73a0e9a7e36e249565e95 Mon Sep 17 00:00:00 2001
From: Michael Banck <mbanck@debian.org>
Date: Mon, 25 Aug 2025 20:50:45 +0200
Subject: [PATCH] Define PS_USE_CLOBBER_ARGV on GNU/Hurd to (re-)enable process
title changes.
Until d2ea2d310dfdc40328aca5b6c52225de78432e01, the PS_USE_PS_STRINGS option
was used on the GNU Hurd. As this option got removed and PS_USE_CLOBBER_ARGV
appears to work fine nowadays on the Hurd, define this one to re-enable process
title changes on this platform.
---
src/backend/utils/misc/ps_status.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/backend/utils/misc/ps_status.c b/src/backend/utils/misc/ps_status.c
index 4df25944deb..c141caa00ae 100644
--- a/src/backend/utils/misc/ps_status.c
+++ b/src/backend/utils/misc/ps_status.c
@@ -52,7 +52,7 @@ bool update_process_title = DEFAULT_UPDATE_PROCESS_TITLE;
#define PS_USE_SETPROCTITLE_FAST
#elif defined(HAVE_SETPROCTITLE)
#define PS_USE_SETPROCTITLE
-#elif defined(__linux__) || defined(__sun) || defined(__darwin__)
+#elif defined(__linux__) || defined(__sun) || defined(__darwin__) || defined(__GNU__)
#define PS_USE_CLOBBER_ARGV
#elif defined(WIN32)
#define PS_USE_WIN32
@@ -62,7 +62,7 @@ bool update_process_title = DEFAULT_UPDATE_PROCESS_TITLE;
/* Different systems want the buffer padded differently */
-#if defined(__linux__) || defined(__darwin__)
+#if defined(__linux__) || defined(__darwin__) || defined(__GNU__)
#define PS_PADDING '\0'
#else
#define PS_PADDING ' '
--
2.39.5
Hi,
On Tue, Aug 26, 2025 at 03:55:30PM +0200, Michael Banck wrote:
On Thu, Feb 16, 2023 at 04:52:33PM +1300, Thomas Munro wrote:
Therefore I think it is safe to drop the PS_USE_PS_STRING and
PS_USE_CHANGE_ARGV code branches, remove a bunch of outdated comments
and macro tests, and prune the defunct configure/meson probe.I noticed Postgres no longer updates the process title on the Hurd, this
is because this was removed along other legacy platforms in this commit
as it was using PS_USE_PS_STRING.
By the way, on the back branches from 13-15 (before the above commit)
process title changes don't work either, presumably because __hurd__ (as
opposed to __GNU__ and __gnu_hurd__) has not been defined on GNU/Hurd
for ages (or ever?), see
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/gnu.h#L25
So in case this get backpatched, I think it should be changed to
PS_USE_CLOBBER_ARGV there as well.
Michael
Replying to Michael's message:
/messages/by-id/68adbcd3.500a0220.8d4c9.9460@mx.google.com
Sorry I missed this. I had some trouble with your messages being
deleted as spam, which I've hopefully fixed now...
-#elif defined(__linux__) || defined(__sun) || defined(__darwin__)
+#elif defined(__linux__) || defined(__sun) || defined(__darwin__) ||
defined(__GNU__)Would __gnu_hurd__ be a better bet, less confusable with GNU userspace
stuff? I think these platform macros might come from this file in
GCC:
https://github.com/gcc-mirror/gcc/blob/faf7053346110cbd11fb22ff75f56a964047b19c/gcc/config/gnu.h#L30
But maybe not only there, if __hurd__ (as removed by d2ea2d31)
actually worked...
On Tue, Nov 11, 2025 at 11:04 AM Thomas Munro <thomas.munro@gmail.com> wrote:
/messages/by-id/68adbcd3.500a0220.8d4c9.9460@mx.google.com
Sorry I missed this. I had some trouble with your messages being
deleted as spam, which I've hopefully fixed now...-#elif defined(__linux__) || defined(__sun) || defined(__darwin__) +#elif defined(__linux__) || defined(__sun) || defined(__darwin__) || defined(__GNU__)Would __gnu_hurd__ be a better bet, less confusable with GNU userspace
stuff? I think these platform macros might come from this file in
GCC:https://github.com/gcc-mirror/gcc/blob/faf7053346110cbd11fb22ff75f56a964047b19c/gcc/config/gnu.h#L30
But maybe not only there, if __hurd__ (as removed by d2ea2d31)
actually worked...
I failed to locate a definitive source in a manual or porting guide or
such, but I see patches making the same change in other projects in
their mailing lists[1]https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=__GNU__&submit=Search%21&idxname=bug-hurd&max=20&result=normal&sort=score, so it seems that __GNU__ is indeed their
preferred way of detecting a GNU/Hurd (or IIUC 100% "GNU") system, and
it's certainly not defined on my Debian GNU/Linux machine according to
GCC and Clang. So although it was slightly confusing to this human,
being used to seeing __GNUC__ and similar, it doesn't appear to be
confusing to computers.
Pushed, and back-patched to 16, where it applied without problems.
The REL_{14,15}_STABLE branches don't have commit d2ea2d31. I thought
about doing s/__hurd__/__GNU__/ instead, but it actually said:
#elif (defined(BSD) || defined(__hurd__)) && !defined(__darwin__)
#define PS_USE_CHANGE_ARGV
The right thing to do might be to remove it from there, define
PS_USE_CLOBBER_ARGV like in the newer branches and also apply the
second hunk about padding strategy (in other words: be exactly like
GNU/Linux), but I can't test that. If 14 and 15 are still interesting
to you, let me know if that makes sense and works as expected,
otherwise I'll assume you just want to let sleeping dogs lie.
Hi Thomas,
On Mon, Nov 17, 2025 at 12:54:44PM +1300, Thomas Munro wrote:
On Tue, Nov 11, 2025 at 11:04 AM Thomas Munro <thomas.munro@gmail.com> wrote:
/messages/by-id/68adbcd3.500a0220.8d4c9.9460@mx.google.com
Sorry I missed this. I had some trouble with your messages being
deleted as spam, which I've hopefully fixed now...
(Sorry about that, I think I fixed it now (after Alvaro mentioned it
again to me at pgconf.eu). Ironically, your previous mail from November
11 was flagged as spam by my provider so I didn't see it until now,
either)
-#elif defined(__linux__) || defined(__sun) || defined(__darwin__) +#elif defined(__linux__) || defined(__sun) || defined(__darwin__) || defined(__GNU__)Would __gnu_hurd__ be a better bet, less confusable with GNU userspace
stuff? I think these platform macros might come from this file in
GCC:https://github.com/gcc-mirror/gcc/blob/faf7053346110cbd11fb22ff75f56a964047b19c/gcc/config/gnu.h#L30
But maybe not only there, if __hurd__ (as removed by d2ea2d31)
actually worked...I failed to locate a definitive source in a manual or porting guide or
such, but I see patches making the same change in other projects in
their mailing lists[1], so it seems that __GNU__ is indeed their
preferred way of detecting a GNU/Hurd (or IIUC 100% "GNU") system, and
it's certainly not defined on my Debian GNU/Linux machine according to
GCC and Clang.
Yeah, __GNU__ is the usual way to distinguish that, I didn't even know
about __gnu_hurd__ until I looked up the same file above when I wrote
the patch...
So although it was slightly confusing to this human, being used to
seeing __GNUC__ and similar, it doesn't appear to be confusing to
computers.Pushed, and back-patched to 16, where it applied without problems.
Thanks!
The REL_{14,15}_STABLE branches don't have commit d2ea2d31. I thought
about doing s/__hurd__/__GNU__/ instead, but it actually said:#elif (defined(BSD) || defined(__hurd__)) && !defined(__darwin__)
#define PS_USE_CHANGE_ARGVThe right thing to do might be to remove it from there, define
PS_USE_CLOBBER_ARGV like in the newer branches and also apply the
second hunk about padding strategy (in other words: be exactly like
GNU/Linux), but I can't test that. If 14 and 15 are still interesting
to you, let me know if that makes sense and works as expected,
otherwise I'll assume you just want to let sleeping dogs lie.
I mentioned that in a follow-up[0]/messages/by-id/68add009.170a0220.16b3ca.d01e@mx.google.com to my original mail that you
apparently did not see eiter:
|By the way, on the back branches from 13-15 (before the above commit)
|process title changes don't work either, presumably because __hurd__ (as
|opposed to __GNU__ and __gnu_hurd__) has not been defined on GNU/Hurd
|for ages (or ever?), see
|https://github.com/gcc-mirror/gcc/blob/master/gcc/config/gnu.h#L25
|
|So in case this get backpatched, I think it should be changed to
|PS_USE_CLOBBER_ARGV there as well.
So yeah, I think those would be useful to fix. If you have a patch, I am
happy to test it, or I can come up with one (but not sure I manage this
week).
Thanks,
Michael
[0]: /messages/by-id/68add009.170a0220.16b3ca.d01e@mx.google.com
On Mon, Nov 17, 2025 at 10:36 PM Michael Banck <mbanck@gmx.net> wrote:
I mentioned that in a follow-up[0] to my original mail that you
apparently did not see eiter:|By the way, on the back branches from 13-15 (before the above commit)
|process title changes don't work either, presumably because __hurd__ (as
|opposed to __GNU__ and __gnu_hurd__) has not been defined on GNU/Hurd
|for ages (or ever?), see
|https://github.com/gcc-mirror/gcc/blob/master/gcc/config/gnu.h#L25
|
|So in case this get backpatched, I think it should be changed to
|PS_USE_CLOBBER_ARGV there as well.So yeah, I think those would be useful to fix. If you have a patch, I am
happy to test it, or I can come up with one (but not sure I manage this
week).
Ahh, yeah, I'd missed that one too. The mail is definitely getting
through now, though.
With that information, it seemed pretty clear what to do, so I went
ahead and back-patched to 14 and 15.
Import Notes
Reply to msg id not found: 691aec96.df0a0220.16c901.9e3fSMTPIN_ADDED_BROKEN@mx.google.com