On Mon, Apr 22, 2019 at 1:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > The only explanation I can think of is that the assertion failure was
> > from the core code
>
> That's what I guessed. It might be impractical for amcheck to prevent it,
> but we should try to find out.
On second thought, amcheck is very unlikely to have accessed a corrupt
system catalog index or something at the same time the pgbench_pkey
index was also corrupt. The page image did appear to be from
pgbench_pkey, so it would take two corrupt indexes at the same time
for the assertion failure to be from the core code, outside of
amcheck.
A slightly less insane theory is that this has something to do with
undefined behavior. Hard to imagine how that could make amcheck's test
go away, but I've heard horror stories that were at least
superficially similar to what I have in mind.
In any case, it will be possible to make amcheck avoid undefined
behavior when a page image is corrupt. That seems like a worthy goal,
regardless of the specifics of this case, because amcheck's charter is
to absolutely distrust on-disk state.
> No objection here, as long as it doesn't add an unreasonable amount
> of complexity. (If it does, we might have to think harder about
> what to do.)
I want to do some basic sanity checking of the line pointer against
the page header, to ensure that any index tuple pointer actually
points to memory that it's safe to do a load from (i.e. from the temp
BLCKSZ buffer). I'll add another check to that list:
* Make sure that each line pointer is "lp_off < pd_special". Note that
pg_special is already verified-sane for each page.
These checks are simple and low risk in my opinion. I will come up
with a patch in the next few days.
--
Peter Geoghegan
