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 по дате отправления: