Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Subject: Re: new heapcheck contrib module
From: Mark Dilger <mark.dilger@enterprisedb.com>
In-Reply-To: <43209.1603400779@sss.pgh.pa.us>
Date: Thu, 22 Oct 2020 14:10:55 -0700
Cc: Robert Haas <robertmhaas@gmail.com>,
 Peter Geoghegan <pg@bowt.ie>,
 "Andrey M. Borodin" <x4mmm@yandex-team.ru>,
 Stephen Frost <sfrost@snowman.net>,
 Michael Paquier <michael@paquier.xyz>,
 Amul Sul <sulamul@gmail.com>,
 Dilip Kumar <dilipbalaut@gmail.com>,
 Andres Freund <andres@anarazel.de>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C20AA792-DC40-44B4-863E-719FAD34DA9E@enterprisedb.com>
References: <12ED3DA8-25F0-4B68-937D-D907CFBF08E7@enterprisedb.com>
 <20200420194210.sevnpi4lyghoanxi@alap3.anarazel.de>
 <23E60C3C-C20A-4508-84AC-E0CEA59E784A@enterprisedb.com>
 <CA+TgmobAm8vB1MNQ1taO1et+HxTN8ULnQvEG+grNDqNQTBjbtA@mail.gmail.com>
 <F845AC50-A479-43F3-ADFB-861A4D2AD287@enterprisedb.com>
 <5F743835-3399-419C-8324-2D424237E999@enterprisedb.com>
 <CAFiTN-syyHc3jZoou51v0SR8z0POoNfktqEO6MaGig4YS8mosA@mail.gmail.com>
 <E6F4258A-B661-4F2C-8A35-278C9436930A@enterprisedb.com>
 <CAFiTN-s-VX3DLfqv7OOo0zGCTOZ3xVU9UZ6GgzBZdJTPNnYFNg@mail.gmail.com>
 <885D2EC9-7D06-4903-A17D-72C184A1E1C5@enterprisedb.com>
 <CAFiTN-uYg_PiZ854=5R-D9skratapAHKhaDAG7fhJv-Vn5UhaQ@mail.gmail.com>
 <5CC85F28-F210-47AC-8DA8-EC4E82AF3FD5@enterprisedb.com>
 <CAFiTN-sP5iFJGERTq4a4OLTCzjZKhLC5P6_k2bxQKXnuvdmzGA@mail.gmail.com>
 <CAFiTN-tTg0R5AHvXC1ro9XphroX1wUtc5t91hU_+7DeGTpE5VQ@mail.gmail.com>
 <0C0349EB-DD85-4DA8-82C7-DF70AB714592@enterprisedb.com>
 <BA6E870F-241C-4DDB-B92D-DB39E679C7D4@enterprisedb.com> <CA+Tgm! ! ! !
 obQUdfM2Q7WAR606RR2YehCZ5GHRKBc-VWfRj-1ZUKqDA@mail.gmail.com>
 <C4A3E5AE-CBB2-4E3F-8BAE-29EE216762C2@enterprisedb.com>
 <CAAJ_b96_Xr2a+D0j8xKbOnCzURcVQm0V2DS+T_pfc+wt3BpL8g@mail.gmail.com>
 <9DF93B83-FE46-4EC4-A99D-77A60729FD2D@enterprisedb.com>
 <CA+TgmoZT3kCOaKq6=m5wHGKh_9XQDbCC1LZXL6w_+NMB-n1+mw@mail.gmail.com>
 <CAAJ_b94hsrF4x7UKQj03416fAEXJorUpZ9WhsZZjqgv-4+Wg9A@mail.gmail.com>
 <50F6468F-5A5E-412A-86EC-DF24B549D733@enterprisedb.com>
 <CAAJ_b94+A1Gk5r5sBYbYM2K5hH_gyp_o=+gwJuJhn5ZEm5_rqw@mail.gmail.com>
 <CAAJ_b94Wh_7kM9JuJk7wnNsYSNPdSzz35cOEaE_ZRnPcqvupCg@mail.gmail.com>
 <7D603B53-8078-4AF0-851B-803FF4416501@enterprisedb.com>
 <CA+TgmoZbPtTgkQBGoco39uqKUWuv=0+TOkiNcCuqWWvUkJVuxQ@mail.gmail.com>
 <A4C9E0AE-46BA-457F-A445-4527E5AA5E3C@enterprisedb.com>
 <98265AA9-7BDC-4708-9348-CC1B173BBE1D@enterprisedb.com>
 <CA+Tgmoam+pnGKhWS+RAYCk1eqjhbAPX7Vm69g1VF56xwyxXw+g@mail.gmail.com>
 <209783.1603313248@sss.pgh.pa.us>
 <77A60E99-6054-40FD-A5D6-769C287D4A0F@enterprisedb.com> <CA+TgmoaD5! K6! Uh!
 O2! zddxVCDY2TcR9wSLVurhQYAYpQ0VZPec0og@mail.gmail.com>
 <CA+TgmobGxdm8Tsxawt7LW-qigHRHxD+b17PC+ft9EE+6pMhC9w@mail.gmail.com>
 <721BFA83-EA6F-463D-A9DF-CE78A318B73A@enterprisedb.com>
 <2A7DA1A8-C4AA-43DF-A985-3CA52F4DC775@enterprisedb.com>
 <CA+TgmoaAG0BVk4b6iOYNCeALQ+4DGLmCbqYXqumK1noGq8UpnA@mail.gmail.com>
 <43209.1603400779@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Precedence: bulk


> On Oct 22, 2020, at 2:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>=20
> I wrote:
>> Mark Dilger <mark.dilger@enterprisedb.com> writes:
>>> It is seeking to position 32 and writing '\x77\x77\x77\x77'.  x86_64 =
is
>>> little-endian, and ppc32 and sparc64 are both big-endian, right?
>=20
>> They are, but that should not meaningfully affect the results of
>> that corruption step.  You zapped only one line pointer not
>> several, but it would look the same regardless of endiannness.
>=20
> Oh, wait a second.  ItemIdData has the flag bits in the middle:
>=20
> typedef struct ItemIdData
> {
>    unsigned    lp_off:15,        /* offset to tuple (from start of =
page) */
>                lp_flags:2,       /* state of line pointer, see below =
*/
>                lp_len:15;        /* byte length of tuple */
> } ItemIdData;
>=20
> meaning that for that particular bit pattern, one endianness
> is going to see the flags as 01 (LP_NORMAL) and the other as 10
> (LP_REDIRECT).  The offset/len are corrupt either way, but
> I'd certainly expect that amcheck would produce different
> complaints about those two cases.  So it's unsurprising if
> this test case's output is endian-dependent.

Yeah, I'm already looking at that.  The logic in verify_heapam skips =
over line pointers that are unused or dead, and the test is reporting =
zero corruption (and complaining about that), so it's probably not going =
to help to overwrite all the line pointers with this particular bit =
pattern any more than to just overwrite the first one, as it would just =
skip them all.

I think the test should overwrite the line pointers with a variety of =
different bit patterns, or one calculated to work on all platforms.  =
I'll have to write that up.


=E2=80=94
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company