Re: Is this a problem in GenericXLogFinish()?
От | Amit Kapila |
---|---|
Тема | Re: Is this a problem in GenericXLogFinish()? |
Дата | |
Msg-id | CAA4eK1Kgv2dVpyVP0vEHDO6UdWqDizWrC319OHHD9QgHLJLB9A@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Is this a problem in GenericXLogFinish()? ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Ответы |
RE: Is this a problem in GenericXLogFinish()?
|
Список | pgsql-hackers |
On Thu, Nov 30, 2023 at 12:58 PM Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> wrote: > > > > > Good catch, thank you for reporting! I will investigate more about it and post my > > analysis. > > > > Again, good catch. Here is my analysis and fix patch. > I think it is sufficient to add an initialization for writebuf. > > In the reported case, neither is_prim_bucket_same_wrt nor is_prev_bucket_same_wrt > is set in the WAL record, and ntups is also zero. This means that the wbuf is not > written in the WAL record on primary side (see [1]). > Also, there are no reasons to read (and lock) other buffer page because we do > not modify it. Based on them, I think that just initializing as InvalidBuffer is sufficient. > Agreed. > > I want to add a test case for it as well. I've tested on my env and found that proposed > tuples seems sufficient. > (We must fill the primary bucket, so initial 500 is needed. Also, we must add > many dead pages to lead squeeze operation. Final page seems OK to smaller value.) > > I compared the execution time before/after patching, and they are not so different > (1077 ms -> 1125 ms). > In my environment, it increased from 375ms to 385ms (median of five runs). I think it is acceptable especially if it increases code coverage. Can you once check that? -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: