From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: failing to build preproc.c on solaris with sun studio |
Date: | 2022-08-07 01:09:27 |
Message-ID: | 20220807010927.5mjyzotxznuwsjla@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2022-08-06 17:59:54 -0700, Noah Misch wrote:
> 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.
My point wasn't about the future - *today* a compile with normal settings
doesn't work, on a machine with a reasonable amount of ram. Who does it help
if one person can get postgres to compile with some applied magic - normal
users won't.
And it's not a cost free thing to support, e.g. I tried to build because
solaris with suncc forces me to generate with_gnu_ld when generating a
compatible Makefile.global for pgxs with meson.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-08-07 01:10:09 | Re: failing to build preproc.c on solaris with sun studio |
Previous Message | Noah Misch | 2022-08-07 00:59:54 | Re: failing to build preproc.c on solaris with sun studio |