Re: pgsql: Move gramparse.h to src/backend/parser

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgsql: Move gramparse.h to src/backend/parser
Дата
Msg-id 1368269.1760589291@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgsql: Move gramparse.h to src/backend/parser  (John Naylor <johncnaylorls@gmail.com>)
Список 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 по дате отправления: