Horton

Thread

Commits

  1. Switch the semaphore API on Solaris to unnamed POSIX.

  2. Fix aclitemout() to work during early bootstrap.

  1. Areas for Solaris support modernization

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-03-02T02:05:08Z

    I notice that new BF member icarus (OpenIndiana/Illumos)
has been sort of working in recent branches, but when it
gets to trying to run a bunch of test scripts in parallel,
it falls over with errors like

2026-03-01 15:00:29.746 EST [758322] FATAL:  could not create semaphores: No space left on device
2026-03-01 15:00:29.746 EST [758322] DETAIL:  Failed system call was semget(2575969, 17, 03600).

I can reproduce that on a local OpenIndiana image.  Now, we could
tell people they need to increase SEMMNI/SEMMNS, but there's another
answer: unnamed POSIX semaphores seem to work just fine, at least on
recent OpenIndiana.  (And the docs I can find suggest that Solaris
has had them for decades.)  So I think maybe we should add
PREFERRED_SEMAPHORES=UNNAMED_POSIX
as we just did for AIX.

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.

			regards, tom lane

  2. Re: Areas for Solaris support modernization

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-03-02T02:50:27Z

    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

  3. Re: Areas for Solaris support modernization

    Greg Burd <greg@burd.me> — 2026-03-02T19:48:11Z

    On Sun, Mar 1, 2026, at 9:50 PM, Tom Lane wrote:
> 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.

Hey Tom,

Thanks for digging into this, it's been on my mind for a while to get back to "tending to the animals".

> 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__)".

I've started a build/test on "icarus" with your patch applied.  I'll let you know how it goes, hopefully that won't take as long now.

> 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

best.

-greg

> diff --git a/src/backend/utils/misc/ps_status.c 
> b/src/backend/utils/misc/ps_status.c
> index 51dce24947a..f5fc7124211 100644
> --- a/src/backend/utils/misc/ps_status.c
> +++ b/src/backend/utils/misc/ps_status.c
> @@ -39,6 +39,9 @@ bool		update_process_title = 
> DEFAULT_UPDATE_PROCESS_TITLE;
>   * PS_USE_SETPROCTITLE
>   *	   use the function setproctitle(const char *, ...)
>   *	   (other BSDs)
> + * PS_USE_CHANGE_ARGV
> + *	   assign argv[0] = "string"
> + *	   (Solaris)
>   * PS_USE_CLOBBER_ARGV
>   *	   write over the argv and environment area
>   *	   (Linux and most SysV-like systems)
> @@ -52,7 +55,9 @@ 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(_AIX) || defined(__sun) || 
> defined(__darwin__) || defined(__GNU__)
> +#elif defined(__sun)
> +#define PS_USE_CHANGE_ARGV
> +#elif defined(__linux__) || defined(_AIX) || defined(__darwin__) || 
> defined(__GNU__)
>  #define PS_USE_CLOBBER_ARGV
>  #elif defined(WIN32)
>  #define PS_USE_WIN32
> @@ -223,6 +228,9 @@ save_ps_display_args(int argc, char **argv)
>  		ps_status_new_environ = new_environ;
>  #endif
>  	}
> +#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
> @@ -268,7 +276,7 @@ save_ps_display_args(int argc, char **argv)
> 
>  		argv = new_argv;
>  	}
> -#endif							/* PS_USE_CLOBBER_ARGV */
> +#endif							/* PS_USE_CHANGE_ARGV or PS_USE_CLOBBER_ARGV */
> 
>  	return argv;
>  }
> @@ -305,7 +313,18 @@ 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
>  	/* 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;
>
> Attachments:
> * restore-solaris-ps_status.patch

  4. Re: Areas for Solaris support modernization

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-03-02T20:28:06Z

    "Greg Burd" <greg@burd.me> writes:
> I've started a build/test on "icarus" with your patch applied.  I'll let you know how it goes, hopefully that won't take as long now.

Cool.  Here's also a patch to switch the semaphore API.
I've tested both patches on OpenIndiana, but a confirmation
from icarus would be good.

			regards, tom lane

  5. Re: Areas for Solaris support modernization

    Greg Burd <greg@burd.me> — 2026-03-02T20:40:56Z

    On Mon, Mar 2, 2026, at 3:28 PM, Tom Lane wrote:
> "Greg Burd" <greg@burd.me> writes:
>> I've started a build/test on "icarus" with your patch applied.  I'll let you know how it goes, hopefully that won't take as long now.
>
> Cool.  Here's also a patch to switch the semaphore API.
> I've tested both patches on OpenIndiana, but a confirmation
> from icarus would be good.

Roger, wilco.  As soon as the previous patch run finishes up I'll start another with this additive change set.

best.

-greg

> 			regards, tom lane
>
>
> diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
> index b4914faff1c..c1a3e5b779a 100644
> --- a/doc/src/sgml/runtime.sgml
> +++ b/doc/src/sgml/runtime.sgml
> @@ -1127,13 +1127,8 @@ projadd -c "PostgreSQL DB User" -K 
> "project.max-shm-memory=(privileged,8GB,deny)
>         </para>
> 
>         <para>
> -        Other recommended kernel setting changes for database servers 
> which will
> -        have a large number of connections are:
> -<programlisting>
> -project.max-shm-ids=(priv,32768,deny)
> -project.max-sem-ids=(priv,4096,deny)
> -project.max-msg-ids=(priv,4096,deny)
> -</programlisting>
> +        To run a very large server, or multiple servers concurrently, 
> you
> +        might also need to raise 
> <literal>project.max-shm-ids</literal>.
>         </para>
> 
>         <para>
> diff --git a/meson.build b/meson.build
> index ddf5172982f..40fbbbcd3fe 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -324,6 +324,7 @@ elif host_system == 'openbsd'
> 
>  elif host_system == 'sunos'
>    portname = 'solaris'
> +  sema_kind = 'unnamed_posix'
>    export_fmt = '-Wl,-M@0@'
>    # We need these #defines to get POSIX-conforming versions
>    # of many interfaces (sigwait, getpwuid_r, shmdt, ...).
> diff --git a/src/template/solaris b/src/template/solaris
> index a4d8d38a8f8..ea524fdb2bd 100644
> --- a/src/template/solaris
> +++ b/src/template/solaris
> @@ -1,4 +1,9 @@
>  # src/template/solaris
> 
> +# Prefer unnamed POSIX semaphores if available, unless user overrides choice
> +if test x"$PREFERRED_SEMAPHORES" = x"" ; then
> +  PREFERRED_SEMAPHORES=UNNAMED_POSIX
> +fi
> +
>  # Extra CFLAGS for code that will go into a shared library
>  CFLAGS_SL="-fPIC"
>
> Attachments:
> * change-sema-API-for-Solaris.patch

  6. Re: Areas for Solaris support modernization

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-03-02T22:15:59Z

    "Greg Burd" <greg@burd.me> writes:
> On Sun, Mar 1, 2026, at 9:50 PM, Tom Lane 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, 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__)".

> I've started a build/test on "icarus" with your patch applied.  I'll let you know how it goes, hopefully that won't take as long now.

Oh, now THIS is interesting: I just updated to current OpenIndiana
(previously I was on Dec-2025 or thereabouts), and now ps_status
seems to be working *without* any patch!  It works with the patch
too, but now I'm thinking I hit some bug in their "ps" that got
fixed and perhaps wasn't of long standing.

So maybe we don't need this patch.  I'd be interested to know what
you see on whatever Solaris boxen you have.  Note that the regression
tests will not reveal anything --- you need to eyeball what "ps auxww"
shows for a running postmaster and its children.  With current HEAD
and all-default settings, I see something like

$ ps auxww | grep tgl
...
tgl       17855  0.1  0.6 211008 21792 pts/2    S 22:07:24  0:00 postgres -F
tgl       17860  0.0  0.1 211056 3384 ?        S 22:07:24  0:00 postgres: background writer
tgl       17856  0.0  0.1 211056 3480 ?        S 22:07:24  0:00 postgres: io worker 0
tgl       17857  0.0  0.1 211056 3480 ?        S 22:07:24  0:00 postgres: io worker 1
tgl       17858  0.0  0.1 211040 3112 ?        S 22:07:24  0:00 postgres: io worker 2
tgl       17859  0.0  0.1 211072 3288 ?        S 22:07:24  0:00 postgres: checkpointer
tgl       17862  0.0  0.1 212080 4148 ?        S 22:07:24  0:00 postgres: walwriter
tgl       17863  0.0  0.2 212528 6224 ?        S 22:07:24  0:00 postgres: autovacuum launcher
tgl       17864  0.0  0.2 212512 5940 ?        S 22:07:24  0:00 postgres: logical replication launcher
...

if it's working, and a bunch of identical command lines if not.

			regards, tom lane

  7. Re: Areas for Solaris support modernization

    Greg Burd <greg@burd.me> — 2026-03-03T21:07:11Z

    On Mon, Mar 2, 2026, at 5:15 PM, Tom Lane wrote:
> "Greg Burd" <greg@burd.me> writes:
>> On Sun, Mar 1, 2026, at 9:50 PM, Tom Lane 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, 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__)".
>
>> I've started a build/test on "icarus" with your patch applied.  I'll let you know how it goes, hopefully that won't take as long now.

Hey Tom,

> Oh, now THIS is interesting: I just updated to current OpenIndiana
> (previously I was on Dec-2025 or thereabouts), and now ps_status
> seems to be working *without* any patch!  It works with the patch
> too, but now I'm thinking I hit some bug in their "ps" that got
> fixed and perhaps wasn't of long standing.
>
> So maybe we don't need this patch.  I'd be interested to know what
> you see on whatever Solaris boxen you have.  Note that the regression
> tests will not reveal anything --- you need to eyeball what "ps auxww"
> shows for a running postmaster and its children.  With current HEAD
> and all-default settings, I see something like
>
> $ ps auxww | grep tgl
> ...
> tgl       17855  0.1  0.6 211008 21792 pts/2    S 22:07:24  0:00 
> postgres -F
> tgl       17860  0.0  0.1 211056 3384 ?        S 22:07:24  0:00 
> postgres: background writer
> tgl       17856  0.0  0.1 211056 3480 ?        S 22:07:24  0:00 
> postgres: io worker 0
> tgl       17857  0.0  0.1 211056 3480 ?        S 22:07:24  0:00 
> postgres: io worker 1
> tgl       17858  0.0  0.1 211040 3112 ?        S 22:07:24  0:00 
> postgres: io worker 2
> tgl       17859  0.0  0.1 211072 3288 ?        S 22:07:24  0:00 
> postgres: checkpointer
> tgl       17862  0.0  0.1 212080 4148 ?        S 22:07:24  0:00 
> postgres: walwriter
> tgl       17863  0.0  0.2 212528 6224 ?        S 22:07:24  0:00 
> postgres: autovacuum launcher
> tgl       17864  0.0  0.2 212512 5940 ?        S 22:07:24  0:00 
> postgres: logical replication launcher
> ...
>
> if it's working, and a bunch of identical command lines if not.

$ ps -auxww | grep gburd
...
gburd     37564  0.0  0.6 1180392 85672 ?        S 15:58:03  0:00 /scratch/pg/2026-03-03/bin/postgres -D /scratch/pg/2026-03-03/db
gburd     37565  0.0  0.3 1180392 44376 ?        S 15:58:04  0:00 /scratch/pg/2026-03-03/bin/postgres -D /scratch/pg/2026-03-03/db
gburd     37566  0.0  0.2 1180392 27880 ?        S 15:58:04  0:00 /scratch/pg/2026-03-03/bin/postgres -D /scratch/pg/2026-03-03/db
gburd     37567  0.0  0.2 1180392 27880 ?        S 15:58:04  0:00 /scratch/pg/2026-03-03/bin/postgres -D /scratch/pg/2026-03-03/db
gburd     37568  0.0  0.2 1180392 27912 ?        S 15:58:04  0:00 /scratch/pg/2026-03-03/bin/postgres -D /scratch/pg/2026-03-03/db
gburd     37569  0.0  0.3 1180392 48392 ?        S 15:58:04  0:00 /scratch/pg/2026-03-03/bin/postgres -D /scratch/pg/2026-03-03/db
gburd     37571  0.0  0.3 1184488 45288 ?        S 15:58:04  0:00 /scratch/pg/2026-03-03/bin/postgres -D /scratch/pg/2026-03-03/db
gburd     37572  0.0  0.3 1184904 50304 ?        S 15:58:04  0:00 /scratch/pg/2026-03-03/bin/postgres -D /scratch/pg/2026-03-03/db
gburd     37573  0.0  0.3 1184888 37728 ?        S 15:58:04  0:00 /scratch/pg/2026-03-03/bin/postgres -D /scratch/pg/2026-03-03/db
...

So, not working - and that's the patched version too. :(

$ uname -a
SunOS sun 5.11 illumos-31d3d510d0 sun4u sparc SUNW,A70

$ cat /etc/release
             OpenIndiana Hipster 2025.12 (powered by illumos)
        OpenIndiana Project, part of The Illumos Foundation (C) 2010-2025
                        Use is subject to license terms.
                           Assembled 27 December 2025

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/gcc/13/lib/gcc/sparcv9-sun-solaris2.11/13.4.0/lto-wrapper
Target: sparcv9-sun-solaris2.11
Configured with: /ws/oi-userland/components/developer/gcc-13/gcc-releases-gcc-13.4.0/configure CC=/usr/gcc/13/bin/gcc CXX=/usr/gcc/13/bin/g++ F77=/usr/gcc/13/bin/gfortran FC=/usr/gcc/13/bin/gfortran CFLAGS=-O2 CXXFLAGS=-O2 FFLAGS='  -O3 -mptr64 -mcpu=ultrasparc -mvis -mfsmuld -mno-app-regs' FCFLAGS=-O2 LDFLAGS=-RPT/lib PKG_CONFIG_PATH=/usr/mariadb/10.6/lib/sparcv9/pkgconfig:/usr/openssl/3/lib/sparcv9/pkgconfig:/usr/lib/sparcv9/pkgconfig:/usr/lib/pkgconfig --prefix=/usr/gcc/13 --mandir=/usr/gcc/13/share/man --bindir=/usr/gcc/13/bin --includedir=/usr/include --infodir=/usr/gcc/13/share/info --libdir=/usr/gcc/13/lib --libexecdir=/usr/gcc/13/libexec --localstatedir=/var --sbindir=/usr/gcc/13/sbin --sysconfdir=/etc --localedir=/usr/gcc/13/share/locale --sbindir=/usr/gcc/13/bin --libdir=/usr/gcc/13/lib --libexecdir=/usr/gcc/13/lib --host sparcv9-sun-solaris2.11 --build sparcv9-sun-solaris2.11 --target sparcv9-sun-solaris2.11 --with-pkgversion='OpenIndiana 13.4.0-oi-0' --with-bugurl=https://bugs.openindiana.org --without-gnu-ld --with-ld=/usr/bin/ld --with-build-time-tools=/usr/gnu/sparcv9-sun-solaris2.11/bin --with-gnu-as --with-as=/usr/bin/gas LDFLAGS=-R/usr/gcc/13/lib --with-mulhigh-size=2048 --with-cpu=ultrasparc --with-build-time-tools=/usr/gnu/sparcv9-sun-solaris2.11/bin --with-build-config=no --enable-languages=c,c++,fortran,go,objc --enable-shared --with-system-zlib --enable-plugins --enable-__cxa_atexit --enable-initfini-array --with-diagnostics-urls=auto-if-env enable_frame_pointer=yes
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.4.0 (OpenIndiana 13.4.0-oi-0)

What is your definition of "current OpenIndiana"?  I'm in contact with the maintainers of the distro I use so maybe I can nudge them to update.

I'm on an UltraSPARC 45 running the *only* OpenIndiana distro that still works on this platform.  To answer the implied question, yes I know SPARC is essentially dead but I felt it might have some interesting coverage for us.  I've yet to prove that to be true.

> 			regards, tom lane

The good news is that I think that my attempts to build sparcv9 binaries and/or use clang might be the root cause of the timeouts.  Building with less ambitious goals and using GCC I pass all the tests in a reasonable amount of time.

The diff implementation (/usr/bin/diff) outputs "no differences found" rather than the expected silence and exit 0 so that was causing issues but when I fixed that (by putting a GNU diff in the path first ahead of /usr/bin) all tests pass.  Okay, they pass with your two patches applied.  It takes a loooong time to rebuild so I've not re-tested without those patches (yet) but AFAICT they didn't cause issues and likely helped.

I'll update my build-farm.conf and get icarus flying closer to the Sun again tomorrow.

best.

-greg

  8. Re: Areas for Solaris support modernization

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-03-03T21:27:58Z

    "Greg Burd" <greg@burd.me> writes:
> On Mon, Mar 2, 2026, at 5:15 PM, Tom Lane wrote:
>> Oh, now THIS is interesting: I just updated to current OpenIndiana
>> (previously I was on Dec-2025 or thereabouts), and now ps_status
>> seems to be working *without* any patch!  It works with the patch
>> too, but now I'm thinking I hit some bug in their "ps" that got
>> fixed and perhaps wasn't of long standing.
>> So maybe we don't need this patch.  I'd be interested to know what
>> you see on whatever Solaris boxen you have.

> So, not working - and that's the patched version too. :(

Bleah.

> What is your definition of "current OpenIndiana"?  I'm in contact with the maintainers of the distro I use so maybe I can nudge them to update.

Actually, it's a fresh installation I made yesterday:

Pull down
https://dlc.openindiana.org/isos/hipster/20251026/OI-hipster-text-20251026.iso
(which was the latest version I saw there)
Install in a qemu virtual image
sudo pkg update				(took ~ 1 hour)
... reboot ...
sudo pkg install build-essential	(~ 15min)
sudo cpan IPC::Run			pulls in other stuff for --with-perl
sudo pkg install ninja			needed for meson builds
git clone pgsql

After the "pkg update" it started calling itself a March 2026 version
at login:

$ ssh ...
Last login: Tue Mar  3 21:21:34 2026 from 10.0.2.2
The illumos Project     illumos-b4961920fb      March 2026
$ uname -a
SunOS openindiana 5.11 illumos-b4961920fb i86pc i386 i86pc illumos
$ cat /etc/release
             OpenIndiana Hipster 2025.10 (powered by illumos)
        OpenIndiana Project, part of The Illumos Foundation (C) 2010-2025
                        Use is subject to license terms.
                           Assembled 26 October 2025
$ gcc --version
gcc (OpenIndiana 14.3.0-oi-1) 14.3.0

I don't know enough about this platform to poke further into exactly
what version of ps it has.

> I'm on an UltraSPARC 45 running the *only* OpenIndiana distro that still works on this platform.  To answer the implied question, yes I know SPARC is essentially dead but I felt it might have some interesting coverage for us.  I've yet to prove that to be true.

I'm quite on board with having some SPARC hardware in the buildfarm.
I'm running an ancient PPC Mac animal for exactly the same reasons.

			regards, tom lane

  9. Re: Areas for Solaris support modernization

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-03-12T15:07:25Z

    "Greg Burd" <greg@burd.me> writes:
> errfinish+0x288(1008310c9, 70f, 100832730, 100bff148, 100bff208, 0)
> ...
> aclitemout+0xf4(100cfa668, 1, 0, 100cfa10f, 100cfa600, 100cf9960)
> FunctionCall1Coll+0x2c(100cfa120, 0, 100cfa600, 0, 100cfa10f, 7)
> array_out+0x700(2, 0, 100cfa610, 100cfa650, 100cfa638, 0)
> FunctionCall1Coll+0x2c(ffffffff7fffed00, 0, 100cfa5e8, 0, 100bff150, 2ef)
> OidOutputFunctionCall+0x18(2ef, 100cfa5e8, 409, 100c01150, 100, ffffffff7fffed00)
> InsertOneValue+0x2a4(100cfa058, e8, 1009a6f60, 100ccdb84, 40a, 100be5388)

Oh ... you are running it at max debug level, aren't you.
So InsertOneValue tries to print out the inserted value,
and that doesn't work because I didn't hot-wire aclitemout
for bootstrap mode, only aclitemin.

I'm away on vacation, but will fix that when I return.
In the meantime, backing down initdb's debug level to
something less than DEBUG4 should get you past that.

			regards, tom lane

  10. Re: Areas for Solaris support modernization

    Greg Burd <greg@burd.me> — 2026-03-12T21:19:13Z

    On Thu, Mar 12, 2026, at 11:07 AM, Tom Lane wrote:
> "Greg Burd" <greg@burd.me> writes:
>> errfinish+0x288(1008310c9, 70f, 100832730, 100bff148, 100bff208, 0)
>> ...
>> aclitemout+0xf4(100cfa668, 1, 0, 100cfa10f, 100cfa600, 100cf9960)
>> FunctionCall1Coll+0x2c(100cfa120, 0, 100cfa600, 0, 100cfa10f, 7)
>> array_out+0x700(2, 0, 100cfa610, 100cfa650, 100cfa638, 0)
>> FunctionCall1Coll+0x2c(ffffffff7fffed00, 0, 100cfa5e8, 0, 100bff150, 2ef)
>> OidOutputFunctionCall+0x18(2ef, 100cfa5e8, 409, 100c01150, 100, ffffffff7fffed00)
>> InsertOneValue+0x2a4(100cfa058, e8, 1009a6f60, 100ccdb84, 40a, 100be5388)
>
> Oh ... you are running it at max debug level, aren't you.
> So InsertOneValue tries to print out the inserted value,
> and that doesn't work because I didn't hot-wire aclitemout
> for bootstrap mode, only aclitemin.

Hey Tom,

I'm not sure what "hot-wire" means, but I put a quick patch together that sets it to NULL when bootstrapping for now.  I'm building and testing now with the *three* patches, hopefully it'll complete in < 4hrs.

> I'm away on vacation, but will fix that when I return.
> In the meantime, backing down initdb's debug level to
> something less than DEBUG4 should get you past that.

Enjoy the vacation, please ignore me and this issue until you get back.  The tests might be done by then...

best.

-greg

> 			regards, tom lane

  11. Re: Areas for Solaris support modernization

    Greg Burd <greg@burd.me> — 2026-03-13T10:42:43Z

    On Thu, Mar 12, 2026, at 5:19 PM, Greg Burd wrote:
> On Thu, Mar 12, 2026, at 11:07 AM, Tom Lane wrote:
>> "Greg Burd" <greg@burd.me> writes:
>>> errfinish+0x288(1008310c9, 70f, 100832730, 100bff148, 100bff208, 0)
>>> ...
>>> aclitemout+0xf4(100cfa668, 1, 0, 100cfa10f, 100cfa600, 100cf9960)
>>> FunctionCall1Coll+0x2c(100cfa120, 0, 100cfa600, 0, 100cfa10f, 7)
>>> array_out+0x700(2, 0, 100cfa610, 100cfa650, 100cfa638, 0)
>>> FunctionCall1Coll+0x2c(ffffffff7fffed00, 0, 100cfa5e8, 0, 100bff150, 2ef)
>>> OidOutputFunctionCall+0x18(2ef, 100cfa5e8, 409, 100c01150, 100, ffffffff7fffed00)
>>> InsertOneValue+0x2a4(100cfa058, e8, 1009a6f60, 100ccdb84, 40a, 100be5388)
>>
>> Oh ... you are running it at max debug level, aren't you.
>> So InsertOneValue tries to print out the inserted value,
>> and that doesn't work because I didn't hot-wire aclitemout
>> for bootstrap mode, only aclitemin.
>
> Hey Tom,
>
> I'm not sure what "hot-wire" means, but I put a quick patch together 
> that sets it to NULL when bootstrapping for now.  I'm building and 
> testing now with the *three* patches, hopefully it'll complete in < 
> 4hrs.

That built fine and test-world passed.  I'll see if I can get the build-farm scripts to run against my local branch/changes to see if that too passes.  Fingers crossed.

-greg

>> I'm away on vacation, but will fix that when I return.
>> In the meantime, backing down initdb's debug level to
>> something less than DEBUG4 should get you past that.
>
> Enjoy the vacation, please ignore me and this issue until you get back. 
>  The tests might be done by then...
>
> best.
>
> -greg
>
>> 			regards, tom lane
> Attachments:
> * v20260312c-0001-Restore-PS_USE_CHANGE_ARGV-for-Solaris.patch
> * v20260312c-0002-Switch-the-semaphore-API-on-Solaris-to-un.patch
> * v20260312c-0003-Make-aclitemout-work-during-bootstrap-mod.patch

  12. Re: Areas for Solaris support modernization

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-03-14T18:13:22Z

    "Greg Burd" <greg@burd.me> writes:
> That built fine and test-world passed.  I'll see if I can get the build-farm scripts to run against my local branch/changes to see if that too passes.  Fingers crossed.

Great.  I pushed the aclitemout patch I'd already written (which is
functionally the same as yours) and also the semaphore API change.
It's not clear to me where we are on the ps_status business though.
You indicated that patch wasn't resulting in the desired ps output
for you, so it seems like maybe more investigation is needed.

			regards, tom lane

  13. Re: Areas for Solaris support modernization

    Greg Burd <greg@burd.me> — 2026-03-14T18:59:30Z

    On Sat, Mar 14, 2026, at 2:13 PM, Tom Lane wrote:
> "Greg Burd" <greg@burd.me> writes:
>> That built fine and test-world passed.  I'll see if I can get the build-farm scripts to run against my local branch/changes to see if that too passes.  Fingers crossed.
>
> Great.  I pushed the aclitemout patch I'd already written (which is
> functionally the same as yours) and also the semaphore API change.
> It's not clear to me where we are on the ps_status business though.
> You indicated that patch wasn't resulting in the desired ps output
> for you, so it seems like maybe more investigation is needed.

Thanks Tom, I'll review the ps_status patch again and let you know if I can get it to work.  I appreciate your help with "icarus", hopefully this means it'll be healthy (and provide some value) going forward.

best.

-greg

> 			regards, tom lane