Re: longfin and tamandua aren't too happy but I'm not sure why

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: longfin and tamandua aren't too happy but I'm not sure why
Дата
Msg-id 4033181.1664395633@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: longfin and tamandua aren't too happy but I'm not sure why  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: longfin and tamandua aren't too happy but I'm not sure why  (Andres Freund <andres@anarazel.de>)
Re: longfin and tamandua aren't too happy but I'm not sure why  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Yeah, I suppose I have to get in the habit of looking at CI before
> committing anything. It's sort of annoying to me, though. Here's a
> list of the follow-up fixes I've so far committed:

> 1. headerscheck
> 2. typos
> 3. pg_buffercache's meson.build
> 4. compiler warning
> 5. alignment problem
> 6. F_INTEQ/F_OIDEQ problem

> CI caught (1), (3), and (4). The buildfarm caught (1), (5), and (6).
> The number of buildfarm failures that I would have avoided by checking
> CI is less than the number of extra things I had to fix to keep CI
> happy, and the serious problems were caught by the buildfarm, not by
> CI.

That seems like an unfounded complaint.  You would have had to fix
(3) and (4) in any case, on some time schedule or other.  I agree
that it'd be good if CI did some 32-bit testing so it could have
caught (5) and (6), but that's being worked on.

> So I guess the way you're supposed to know that you need to
> update meson.build that is by looking at CI, but CI is also the only
> reason it's necessary to carry about meson.build in the first place.

Not so.  People are already using meson in preference to the makefiles
for some things, I believe.  And we're expecting that meson will
supplant the MSVC scripts pretty soon and the makefiles eventually.

> And like the existing buildfarm, it's severely under-documented.

That complaint I agree with.  A wiki page is a pretty poor substitute
for in-tree docs.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: A potential memory leak on Merge Join when Sort node is not below Materialize node
Следующее
От: Nathan Bossart
Дата:
Сообщение: Re: predefined role(s) for VACUUM and ANALYZE