On Wed, Aug 29, 2018 at 3:30 PM Yugo Nagata <nag...@sraoss.co.jp> wrote: > > On Wed, 29 Aug 2018 14:39:10 +0530 > Amit Kapila <amit.kapil...@gmail.com> wrote: > > > On Tue, Aug 28, 2018 at 2:51 PM Peter Eisentraut > > <peter.eisentr...@2ndquadrant.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