Re: Old Postgresql version on i7-1165g7

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Old Postgresql version on i7-1165g7
Date: 2021-04-13 14:45:28
Message-ID: 3190188.1618325128@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Justin Pryzby <pryzby(at)telsasoft(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2021-04-13 14:48:02 Re: [PATCH] Identify LWLocks in tracepoints
Previous Message Petr Jelinek 2021-04-13 14:37:47 Re: Truncate in synchronous logical replication failed