Re: failing to build preproc.c on solaris with sun studio

From: Noah Misch <noah(at)leadboat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: failing to build preproc.c on solaris with sun studio
Date: 2022-08-07 00:25:52
Message-ID: 20220807002552.GB3981561@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Aug 06, 2022 at 08:05:14PM -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2022-08-06 16:09:24 -0700, Noah Misch wrote:
> >> From the earliest days of wrasse, the compiler used too much RAM to build
> >> preproc.o with --enable-debug. As of 2021-04, the compiler's "acomp" phase
> >> needed 10G in one process, and later phases needed 11.6G across two processes.
> >> Compilation wrote 3.7G into TMPDIR. Since /tmp consumes RAM+swap, overriding
> >> TMPDIR relieved 3.7G of RAM pressure. Even with those protections, wrasse
> >> intermittently reaches the 14G limit I impose (via "ulimit -v 14680064"). I
> >> had experimented with different optimization levels, but that didn't help.
>
> > Yikes. And it's not like newer compiler versions are likely to be forthcoming
> > (12.6 is newest and is from 2017...). Wonder if we should just require gcc on
> > solaris... There's a decent amount of stuff we could rip out in that case.
>
> Seems like it's only a matter of time before we add enough stuff to
> the grammar that the build fails, period.

I wouldn't worry about that enough to work hard in advance. The RAM usage can
grow by about 55% before that's a problem. (The 14G ulimit can tolerate a
raise.) By then, the machine may be gone or have more RAM. Perhaps even
Bison will have changed its code generation. If none of those happen, I could
switch to gcc, hack things to use gcc for just preproc.o, etc.

> So there's something pretty bloated there. It doesn't seem like
> ecpg's additional productions should justify a nigh 50% code
> size increase.

True.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2022-08-07 00:36:27 Re: logical decoding and replication of sequences
Previous Message Tom Lane 2022-08-07 00:25:13 Re: Cleaning up historical portability baggage