Dead code in ps_status.c - Mailing list pgsql-hackers

From Thomas Munro
Subject Dead code in ps_status.c
Date
Msg-id CA+hUKGJMNGUAqf27WbckYFrM-Mavy0RKJvocfJU=J2XcAZyv+w@mail.gmail.com
Whole thread Raw
Responses Re: Dead code in ps_status.c
List pgsql-hackers
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.

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum
Next
From: Amit Kapila
Date:
Subject: Re: Support logical replication of DDLs