From: Tom Lane <tgl@sss.pgh.pa.us>
To: Greg Stark <stark@mit.edu>
cc: Thomas Munro <thomas.munro@gmail.com>,
        Tomas Vondra <tomas.vondra@enterprisedb.com>,
        Daniel Gustafsson <daniel@yesql.se>,
        Stephen Frost <sfrost@snowman.net>,
        Alvaro Herrera <alvherre@2ndquadrant.com>,
        Andres Freund <andres@anarazel.de>,
 David Steele <david@pgmasters.net>,
        Dmitry Dolgov <9erthalion6@gmail.com>,
        Jakub Wartak <Jakub.Wartak@tomtom.com>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: WIP: WAL prefetch (another approach)
In-reply-to: 
 <CAM-w4HP+PSgiToDsq6RkGjAftZO7EbjvfkPMqHtsaY9CbVS5CQ@mail.gmail.com>
References: 
 <CA+hUKGJ1=pOiNjSgXYJnjE3OyRtp8tjMRcON256e5EFpzPpgtA@mail.gmail.com>
 <8dd2dcc2-0b6b-a4ab-c1b3-032c0a5ab1c3@enterprisedb.com>
 <CA+hUKGKmkKfH1h9XG5ctYCgqeOHGdN5bHMoQMZLR=+kLY0PQzA@mail.gmail.com>
 <CA+hUKGLsF8sEE+n3qoaV6+XjmYEwYoFVDbLPbYTGz7oGkL=iZA@mail.gmail.com>
 <CA+hUKG+a4wn7B-qBu9SLc1HAbZRSKbp1Ep=rDeveM-UQz84+jg@mail.gmail.com>
 <773932.1619022622@sss.pgh.pa.us>
 <b971373e-5f05-e691-d83c-c72a4f67167b@enterprisedb.com>
 <CA+hUKGLQqsNBXXZ6uXFi7L9iqx-4ZSuiAvKiPqDtRQs+yFD9ew@mail.gmail.com>
 <CA+hUKGJKDibdw5HzOdgh+tFsA7=wwJ3O6p+qYwbgAD_xkLWA3Q@mail.gmail.com>
 <CAOuzzgrn7iKnFRsB4MHp3UisEQAGgZMbk_ViTN4HV4-Ksq8zCg@mail.gmail.com>
 <CA+hUKGKLakuWXsHuOXYYYyk-CiZKgcqXgzwKb61d9nrpgn5eww@mail.gmail.com>
 <5B6070FF-5869-4A84-88BC-2D04EDCDB858@yesql.se>
 <CA+hUKGJ7OqpdnbSTq5oK=djSeVW2JMnrVPSm8JC-_dbN6Y7bpw@mail.gmail.com>
 <a6915477-c675-7959-28b2-5b8fa60f44fc@enterprisedb.com>
 <CA+hUKG+NRzF7qPdjrJg3OqvfFO-yFCLLTUB9wmVH71zbki3G1Q@mail.gmail.com>
 <477464.1637981215@sss.pgh.pa.us> <13!
 70655.1639767599@sss.pgh.pa.us>
 <CAM-w4HO3vJwW9ZsyUSS095HwzMNc7ZPuSkC7h2rqakixwkRQVQ@mail.gmail.com>
 <1374737.1639770826@sss.pgh.pa.us>
 <CAM-w4HOsD0jMhcnfqiUYCdA6MJDDRDkuHBfem_ihLBOATxHn5Q@mail.gmail.com>
 <1426276.1639784421@sss.pgh.pa.us>
 <CAM-w4HP+PSgiToDsq6RkGjAftZO7EbjvfkPMqHtsaY9CbVS5CQ@mail.gmail.com>
Comments: In-reply-to Greg Stark <stark@mit.edu>
	message dated "Fri, 17 Dec 2021 18:55:50 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1431255.1639787893.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 17 Dec 2021 19:38:13 -0500
Message-ID: <1431256.1639787893@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1431256.1639787893%40sss.pgh.pa.us>
Precedence: bulk

Greg Stark <stark@mit.edu> writes:
> But the bigger question is. Are we really concerned about this flaky
> problem? Is it worth investing time and money on? I can get money to
> go buy a G4 or G5 and spend some time on it. It just seems a bit...
> niche. But if it's a real bug that represents something broken on
> other architectures that just happens to be easier to trigger here it
> might be worthwhile.

TBH, I don't know.  There seem to be three plausible explanations:

1. Flaky hardware in my unit.
2. Ancient macOS bug, as Andres suggested upthread.
3. Actual PG bug.

If it's #1 or #2 then we're just wasting our time here.  I'm not
sure how to estimate the relative probabilities, but I suspect
#3 is the least likely of the lot.

FWIW, I did just reproduce the problem on that machine with current HEAD:

2021-12-17 18:40:40.293 EST [21369] FATAL:  inconsistent page found, rel 1=
663/167772/2673, forknum 0, blkno 26
2021-12-17 18:40:40.293 EST [21369] CONTEXT:  WAL redo at C/3DE3F658 for B=
tree/INSERT_LEAF: off 208; blkref #0: rel 1663/167772/2673, blk 26 FPW
2021-12-17 18:40:40.522 EST [21365] LOG:  startup process (PID 21369) exit=
ed with exit code 1

That was after only five loops of the regression tests, so either
I got lucky or the failure probability has increased again.

In any case, it seems clear that the problem exists independently of
Munro's patches, so I don't really think this question should be
considered a blocker for those.

			regards, tom lane