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
|
Список | 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 по дате отправления: