Tom Lane писал 2021-04-13 17:45:
> Justin Pryzby <pryzby@telsasoft.com> writes:
>> On Fri, Apr 09, 2021 at 04:28:25PM +0300, Yura Sokolov wrote:
>>> Occasinally I found I'm not able to `make check` old Postgresql
>>> versions.
>
>>> I've bisected between REL_11_0 and "Rename pg_rewind's
>>> copy_file_range()"
>>> and
>>> found 372728b0d49552641f0ea83d9d2e08817de038fa
>>>> Replace our traditional initial-catalog-data format with a better
>>>> design.
>>> This is first commit where `make check` doesn't fail during initdb on
>>> my
>>> machine.
>
>> This doesn't make much sense or help much, since 372728b doesn't
>> actually
>> change the catalogs, or any .c file.
>
> It could make sense if some part of the toolchain that was previously
> used to generate postgres.bki doesn't work right on that machine.
> Overall though I'd have thought that 372728b would increase not
> decrease our toolchain footprint. It also seems unlikely that a
> recent Ubuntu release would contain toolchain bugs that we hadn't
> already heard about.
>
>> You used make clean too, right ?
>
> Really, when bisecting, you need to use "make distclean" or even
> "git clean -dfx" between steps, or you may get bogus results,
> because our makefiles aren't that great about tracking dependencies,
> especially when you move backwards in the history.
>
> So perhaps a more plausible theory is that this bisection result
> is wrong because you weren't careful enough.
>
> regards, tom lane
Sorry for missing mail for a week.
I believe I cleaned before each step since I'm building in external
directory
and cleanup is just `rm * -r`.
But I'll repeat bisecting tomorrow to be sure.
I don't think it is really PostgreSQL or toolchain bug. I believe it is
some
corner case that were changed in new Intel CPU.
With regards,
Yura Sokolov.
