Re: Areas for Solaris support modernization

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: "Greg Burd" <greg(at)burd(dot)me>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: Areas for Solaris support modernization
Date: 2026-03-02 02:50:27
Message-ID: 476159.1772419827@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Also, while playing with said local OpenIndiana image, I noticed
> that ps_status.c isn't working: "ps auxww" shows all the child
> processes with the same command line as the postmaster. I thought
> maybe we'd diked out something important in d2ea2d310, but none
> of the code removed there claims to apply to Solaris. So maybe
> it never worked on Solaris? Anyway, there's room for improvement
> there if anyone cares to investigate.

Huh: after a bit of testing, it seems that the PS_USE_CHANGE_ARGV
mode removed by d2ea2d310 is indeed the right thing to use on
Solaris. Looking back at that discussion thread, we were a bit
confused about which predefined macros are provided on Solaris.
To believe that the pre-existing code actually worked on Solaris,
you'd have to assume that "BSD" is predefined on that platform.
It does not get defined on my OpenIndiana image, but maybe sometime
in the stone age Solaris defined it?

Anyway, here's a slightly cleaned-up reversion of the relevant
bits of d2ea2d310, with PS_USE_CHANGE_ARGV now selected by
"defined(__sun)" not the previous logic
"(defined(BSD) || defined(__hurd__)) && !defined(__darwin__)".

BTW, I notice that with this, PS_PADDING is set to '\0'
in exactly the cases that select PS_USE_CLOBBER_ARGV.
I'm not inclined to merge the logic, because maybe we'll
find some weird platform where the conditions are different.
But it seems plausible and comforting that there are
fewer underlying behaviors than we thought.

regards, tom lane

Attachment Content-Type Size
restore-solaris-ps_status.patch text/x-diff 2.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2026-03-02 02:54:08 Re: CREATE TABLE LIKE INCLUDING TRIGGERS
Previous Message Michael Paquier 2026-03-02 02:35:02 Re: typo in alter_table.sgml (was: Re: pgsql: Allow ALTER COLUMN SET EXPRESSION on virtual columns with CHECK)