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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] hash index on unlogged tables doesn't behave as expected
Дата
Msg-id CAB7nPqRVHB+-n+8r1KDNcCbBDLCVEtiEZ4EVdK9p+wg3t4o4pw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] hash index on unlogged tables doesn't behave asexpected  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Ответы Re: [HACKERS] hash index on unlogged tables doesn't behave as expected  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
(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 would go as far as spreading a
method similar to ginbuildempty() to all the AMs as delayed
checkpoints guarantee that buffers are correctly flushed when marked
as dirty.
-- 
Michael



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

Предыдущее
От: Mithun Cy
Дата:
Сообщение: Re: [HACKERS] Proposal : For Auto-Prewarm.
Следующее
От: Alik Khilazhev
Дата:
Сообщение: Re: [HACKERS] [WIP] Zipfian distribution in pgbench