Re: pgsql: Move gramparse.h to src/backend/parser - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql: Move gramparse.h to src/backend/parser
Date
Msg-id 1368269.1760589291@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: Move gramparse.h to src/backend/parser  (John Naylor <johncnaylorls@gmail.com>)
List pgsql-committers
John Naylor <johncnaylorls@gmail.com> writes:
> On Wed, Oct 15, 2025 at 2:49 PM Anton A. Melnikov
> <a.melnikov@postgrespro.ru> wrote:
>> Maybe backpatch [2] to all supported versions not just 16+?

> That only changed src/backend/common.mk, so that's not going to affect
> contrib. I looked, and contrib/contrib-global.mk doesn't have any
> extra *.bc file handling to begin with (as expected). Also, that fix
> was in response to a specific change in dependencies, so I don't see
> how it's directly applicable to earlier branches. Maybe there is
> something to be done here, but with such a sporadic failure, I'm not
> sure what.

Yeah.  One build failure in three years does not sound to me like
something to panic about.  It sounds more like a local problem.
Also, I note that alligator is self-described as running a
"gcc experimental (nightly build)" compiler, so temporary build
glitches on it are hardly unexpected.

It seems like there's an increasing number of buildfarm animals whose
aims are less "test Postgres" than "test platform X by building
Postgres on it".  alligator is not the only experimental-tool-chain
animal, and fruitcrow (GNU Hurd) is another example we've been seeing
failures from lately.  I don't want to tell those folk to go away,
but maybe we should have some kind of annotation about "platform not
believed stable" to remind us not to put huge amounts of effort into
transient failures on those animals.

            regards, tom lane



pgsql-committers by date:

Previous
From: John Naylor
Date:
Subject: Re: pgsql: Move gramparse.h to src/backend/parser
Next
From: Amit Langote
Date:
Subject: pgsql: Fix EPQ crash from missing partition directory in EState