Re: hash index on unlogged tables doesn't behave as expected

On Fri, Jul 14, 2017 at 6:02 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> (catching up finally with this thread)
>
> On Mon, Jul 10, 2017 at 11:57 AM, Kyotaro HORIGUCHI
> <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> At Mon, 10 Jul 2017 14:58:13 +0530, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote in <CAA4eK1JYyO5Hcxx4rP0jb=JmMC4qvY1YvG9UvkwNr5qrojsOPw(at)mail(dot)gmail(dot)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