Re: pg_verify_checksums failure with hash indexes
От | Amit Kapila |
---|---|
Тема | Re: pg_verify_checksums failure with hash indexes |
Дата | |
Msg-id | CAA4eK1JBERTYjm6LgyfD6iYKqfCsCrZUc0=RvLcZOOn5NoffKg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_verify_checksums failure with hash indexes (Yugo Nagata <nagata@sraoss.co.jp>) |
Ответы |
Re: pg_verify_checksums failure with hash indexes
|
Список | pgsql-hackers |
On Wed, Aug 29, 2018 at 3:30 PM Yugo Nagata <nagata@sraoss.co.jp> wrote: > > On Wed, 29 Aug 2018 14:39:10 +0530 > Amit Kapila <amit.kapila16@gmail.com> wrote: > > > On Tue, Aug 28, 2018 at 2:51 PM Peter Eisentraut > > <peter.eisentraut@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
В списке pgsql-hackers по дате отправления: