Dead code in ps_status.c

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Dead code in ps_status.c
Date: 2023-02-16 03:52:33
Message-ID: CA+hUKGJMNGUAqf27WbckYFrM-Mavy0RKJvocfJU=J2XcAZyv+w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
0001-Remove-obsolete-code-from-ps_status.c.patch text/x-patch 7.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2023-02-16 04:00:52 Re: Support logical replication of DDLs
Previous Message Masahiko Sawada 2023-02-16 03:24:16 Re: [PoC] Improve dead tuple storage for lazy vacuum