Re: pg_verify_checksums failure with hash indexes

Поиск
Список
Период
Сортировка
От Yugo Nagata
Тема Re: pg_verify_checksums failure with hash indexes
Дата
Msg-id 20180830152804.a7c87ca78dfc140fa5e5a7d1@sraoss.co.jp
обсуждение исходный текст
Ответ на Re: pg_verify_checksums failure with hash indexes  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список pgsql-hackers
On Thu, 30 Aug 2018 15:01:24 +0900 (Tokyo Standard Time)
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote:

> At Wed, 29 Aug 2018 20:10:15 +0900, Yugo Nagata <nagata@sraoss.co.jp> wrote in
<20180829201015.d9d4fde2748910e86a13c0da@sraoss.co.jp>
> > On Wed, 29 Aug 2018 16:01:53 +0530
> > Amit Kapila <amit.kapila16@gmail.com> wrote:
> > 
> > > > 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.
> > 
> > Thank you for your explanation.  I understood  this way could make the
> > codes complicated, so I think the way you posted is better.
> 
> FWIW, I confirmed that this is the only place where smgrextend
> for non-zero pages is not preceded by checksum calculation.

I also confirmed this. I didn't know calling PageSetChecksumInplace
before smgrextend for non-zero pages was a typical coding pattern.
Thanks.

Regards,
-- 
Yugo Nagata <nagata@sraoss.co.jp>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Yugo Nagata
Дата:
Сообщение: Re: Fix comments of IndexInfo
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: "Write amplification" is made worse by "getting tired" whileinserting into nbtree secondary indexes (Was: Why B-Tree suffix truncation matters)