On Fri, Jul 14, 2017 at 6:02 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > (catching up finally with this thread) > > On Mon, Jul 10, 2017 at 11:57 AM, Kyotaro HORIGUCHI > <horiguchi.kyot...@lab.ntt.co.jp> wrote: >> At Mon, 10 Jul 2017 14:58:13 +0530, Amit Kapila <amit.kapil...@gmail.com> >> wrote in <CAA4eK1JYyO5Hcxx4rP0jb=jmmc4qvy1yvg9uvkwnr5qrojs...@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. > > It seems to me that we should really consider logging a full page of > the bitmap and meta pages for init forks as this is the common > practice used by all the other AMs. >
I think if we really want to go in that direction then it is better to write code separately for hashbuildempty, rather than adding special purpose logic in _hash_init for init forks. As to the comparison with other indexes, the logic of hash index is slightly tricky (as I have already explained in email up thread) as compared to other indexes, so we should not force ourselves to do that way if it can be integrated with logged index creation path. I am not against doing that way as it has some merit, but the advantage seems to be thin. Let's not argue endlessly on this point because it is not that I have not considered it doing the way you are saying (in fact I have mentioned that in my first e-mail). Let us wait for an opinion from others and or from committers. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
