On Sat, Jul 15, 2017 at 8:20 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > 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. >
I do agree with Amit. I think hash index is slightly trickier (in terms of how it is organised) than other indexes and that could be the reason for maintaining common code for hashbuild and hashbuildempty. -- With Regards, Ashutosh Sharma 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
