Re: Write Ahead Logging for Hash Indexes

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Write Ahead Logging for Hash Indexes
Дата
Msg-id CAA4eK1KJOfVvFUmi6dcX9Y2-0PFHkomDzGuyoC=aD3Qj9WPpFA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Write Ahead Logging for Hash Indexes  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: Write Ahead Logging for Hash Indexes  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
On Wed, Aug 24, 2016 at 2:37 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> Hi Amit,
>
> Thanks for working on this.
>
> When building with --enable-cassert, I get compiler warning:
>
> hash.c: In function 'hashbucketcleanup':
> hash.c:722: warning: 'new_bucket' may be used uninitialized in this function
>

This warning is from concurrent index patch. I will fix it and post
the patch on that thread.

>
> After an intentionally created crash, I get an Assert triggering:
>
> TRAP: FailedAssertion("!(((freep)[(bitmapbit)/32] &
> (1<<((bitmapbit)%32))))", File: "hashovfl.c", Line: 553)
>
> freep[0] is zero and bitmapbit is 16.
>

Here what is happening is that when it tries to clear the bitmapbit,
it expects it to be set.  Now, I think the reason for why it didn't
find the bit as set could be that after the new overflow page is added
and the bit corresponding to it is set, you might have crashed the
system and the replay would not have set the bit.  Then while freeing
the overflow page it can hit the Assert as mentioned by you.  I think
the problem here could be that I am using REGBUF_STANDARD to log the
bitmap page updates which seems to be causing the issue.  As bitmap
page doesn't follow the standard page layout, it would have omitted
the actual contents while taking full page image and then during
replay, it would not have set the bit, because page doesn't need REDO.
I think here the fix is to use REGBUF_NO_IMAGE as we use for vm
buffers.

If you can send me the detailed steps for how you have produced the
problem, then I can verify after fixing whether you are seeing the
same problem or something else.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
Следующее
От: Claudio Freire
Дата:
Сообщение: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)