On Sat, Aug 06, 2022 at 05:43:50PM -0700, Andres Freund wrote:
> On 2022-08-06 17:25:52 -0700, Noah Misch wrote:
> > On Sat, Aug 06, 2022 at 08:05:14PM -0400, Tom Lane wrote:
> > > Andres Freund <andres@anarazel.de> writes:
> > > > 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.
>
> 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.
