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

On Sat, Jul 15, 2017 at 8:20 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Fri, Jul 14, 2017 at 6:02 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> (catching up finally with this thread)
>>
>> On Mon, Jul 10, 2017 at 11:57 AM, Kyotaro HORIGUCHI
>> <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
>>> 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.
>>
>> 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