Re: [HACKERS] hash index on unlogged tables doesn't behave asexpected - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: [HACKERS] hash index on unlogged tables doesn't behave asexpected
Date
Msg-id 20170711.103208.28854367.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] hash index on unlogged tables doesn't behave as expected  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
At Mon, 10 Jul 2017 18:37:34 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in
<CAA4eK1KGK9pvW=Hn5yd51weEqWxGiKFC8HG8Bs1Ls1Pvfo5kwQ@mail.gmail.com>
> On Mon, Jul 10, 2017 at 3:27 PM, Kyotaro HORIGUCHI
> <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> > Hi,
> >
> > At Mon, 10 Jul 2017 14:58:13 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in
<CAA4eK1JYyO5Hcxx4rP0jb=JmMC4qvY1YvG9UvkwNr5qrojsOPw@mail.gmail.com>
> >
> >> I am also not 100% comfortable with adding flush at two new places,
> >> but that makes the code for fix simpler and fundamentally there is no
> >> problem in doing so.
> >
> > I agree that the patch would be simpler. Ok, I am satisfied with
> > an additional comment for _hash_init and hash_xlog_init_meta_page
> > that describes the reason that _hash_init doesn't/can't use
> > log_newpage and thus requires explicit flushes. Something like
> > the description in [1] would be enough.
> >
> 
> I have modified the comment in hash_xlog_init_meta_page and a
> corresponding function for bitmap page.  However, I think adding
> anything about not using log_newpage in _hash_init doesn't sound good
> to me.  I think you have suggested it so that we don't forget the
> reason for not using log_newpage, but I think that is overkill.  Let
> me know if you have any other concerns?

The modified comment looks perfect. Thanks!

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center




pgsql-hackers by date:

Previous
From: AP
Date:
Subject: Re: [HACKERS] pgsql 10: hash indexes testing
Next
From: Paul A Jungwirth
Date:
Subject: Re: [HACKERS] New partitioning - some feedback