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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Justin Pryzby <pryzby(at)telsasoft(dot)com>
Subject: Re: longfin and tamandua aren't too happy but I'm not sure why
Date: 2022-09-28 20:07:13
Message-ID: 4033181.1664395633@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2022-09-28 20:12:22 Re: predefined role(s) for VACUUM and ANALYZE
Previous Message Tom Lane 2022-09-28 19:57:10 Re: A potential memory leak on Merge Join when Sort node is not below Materialize node