Re: failing to build preproc.c on solaris with sun studio - Mailing list pgsql-hackers

From Tom Lane
Subject Re: failing to build preproc.c on solaris with sun studio
Date
Msg-id 158349.1659834609@sss.pgh.pa.us
Whole thread Raw
In response to Re: failing to build preproc.c on solaris with sun studio  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> On Sat, Aug 06, 2022 at 05:43:50PM -0700, Andres Freund wrote:
>> Sure, we can hack around it in some way. But if we need such hackery to
>> compile postgres with a compiler, what's the point of supporting that
>> compiler?  It's not like sunpro provides with awesome static analysis or such.

> To have a need to decide that, PostgreSQL would need to grow preproc.o such
> that it causes 55% higher RAM usage, and the sunpro buildfarm members extant
> at that time would need to have <= 32 GiB RAM.  I give a 15% chance of
> reaching such conditions, and we don't gain much by deciding in advance.  I'd
> prefer to focus on decisions affecting more-probable outcomes.

I think it's the same rationale as with other buildfarm animals
representing niche systems: we make the effort to support them
in order to avoid becoming locked into a software monoculture.
There's not that many compilers in the farm besides gcc/clang/MSVC,
so I feel anyplace we can find one is valuable.

As per previous discussion, it may well be that gcc/clang are
dominating the field so thoroughly that nobody wants to develop
competitors anymore.  So in the long run this may be a dead end.
But it's hard to be sure about that.  For now, as long as
somebody's willing to do the work to support a compiler that's
not gcc/clang, we should welcome it.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: failing to build preproc.c on solaris with sun studio
Next
From: Bharath Rupireddy
Date:
Subject: Re: Use pg_pwritev_with_retry() instead of write() in dir_open_for_write() to avoid partial writes?