Re: pg_verify_checksums failure with hash indexes

On Wed, Aug 29, 2018 at 3:30 PM Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> wrote:
>
> On Wed, 29 Aug 2018 14:39:10 +0530
> Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> > On Tue, Aug 28, 2018 at 2:51 PM Peter Eisentraut
> > <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> > >
> > > This is reproducible with PG11 and PG12:
> > >
> > > initdb -k data
> > > postgres -D data
> > >
> > > make installcheck
> > > # shut down postgres with Ctrl-C
> > >
> > ..
> > >
> > > The files in question correspond to
> > >
> > > hash_i4_index
> > > hash_name_index
> > > hash_txt_index
> > >
> >
> > I have looked into this problem and found the cause of it. This
> > problem is happening for the empty page in the hash index. On a
> > split, we allocate a new splitpoint's worth of bucket pages wherein we
> > initialize the last page with zero's, this is all fine, but we forgot
> > to set the checksum for that last page. Attached patch fixes the
> > problem for me.
> >
> > Can someone try and share their findings?
>
> I confirmed that this patch fixed the problem by setting a checksum in the last
> page in hash indexes, and pg_veviry_checksum is done successfully.
>

Thanks.

> regression=# select * from page_header(get_raw_page('hash_i4_index',65));
> lsn | checksum | flags | lower | upper | special | pagesize | version | prune_xid
> -----------+----------+-------+-------+-------+---------+----------+---------+-----------
> 0/41CACF0 | 18720 | 0 | 24 | 8176 | 8176 | 8192 | 4 | 0
> (1 row)
>
> By the way, I think we can fix this also by clearing the header information of the last
> page instead of setting a checksum to the unused page although I am not sure which way
> is better.
>

I think that can complicate the WAL logging of this operation which we
are able to deal easily with log_newpage and it sounds quite hacky.
The fix I have posted seems better, but I am open to suggestions.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com