On Thu, Nov 30, 2023 at 12:58 PM Hayato Kuroda (Fujitsu) <kuroda.hay...@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.
