On Sat, Aug 06, 2022 at 06:09:27PM -0700, Andres Freund wrote: > 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.
To me, 32G is on the low side of reasonable, and omitting --enable-debug isn't that magical. (The TMPDIR hack is optional, but I did it to lessen harm to other users of that shared machine.) > 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. There may be a strong argument along those lines. Let's suppose you were to write that revoking sunpro support would save four weeks of Andres Freund time in the meson adoption project. I bet a critical mass of people would like that trade. That's orthogonal to preproc.o compilation RAM usage.
