pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: Andrey M. Borodin <x4mmm@yandex-team.ru>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Amul Sul <sulamul@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: new heapcheck contrib module
Date: Thu, 22 Oct 2020 14:10:55 -0700
Message-ID: <C20AA792-DC40-44B4-863E-719FAD34DA9E@enterprisedb.com> (raw)
In-Reply-To: <43209.1603400779@sss.pgh.pa.us>
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>



> On Oct 22, 2020, at 2:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> 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?
> 
>> 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.
> 
> Oh, wait a second.  ItemIdData has the flag bits in the middle:
> 
> 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;
> 
> 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.


—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company








view thread (218+ messages)  latest in thread

Message-ID: <C20AA792-DC40-44B4-863E-719FAD34DA9E@enterprisedb.com>
Permalink:  ../C20AA792-DC40-44B4-863E-719FAD34DA9E@enterprisedb.com/
Also on:    postgresql.org/message-id/C20AA792-DC40-44B4-863E-719FAD34DA9E@enterprisedb.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: mark.dilger@enterprisedb.com, tgl@sss.pgh.pa.us, robertmhaas@gmail.com, pg@bowt.ie, x4mmm@yandex-team.ru, sfrost@snowman.net, michael@paquier.xyz, sulamul@gmail.com, dilipbalaut@gmail.com, andres@anarazel.de
  Subject: Re: new heapcheck contrib module
  In-Reply-To: <C20AA792-DC40-44B4-863E-719FAD34DA9E@enterprisedb.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox