Re: Is this a problem in GenericXLogFinish()? - Mailing list pgsql-hackers

From Alexander Lakhin
Subject Re: Is this a problem in GenericXLogFinish()?
Date
Msg-id 9aa385d8-fe75-c35b-cf91-31bb3647d977@gmail.com
Whole thread Raw
In response to RE: Is this a problem in GenericXLogFinish()?  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Responses Re: Is this a problem in GenericXLogFinish()?
List pgsql-hackers
Hello Kuroda-san,

30.11.2023 10:28, Hayato Kuroda (Fujitsu) wrote:
> Again, good catch. Here is my analysis and fix patch.
> I think it is sufficient to add an initialization for writebuf.

I agree with the change. It aligns hash_xlog_squeeze_page() with
hash_xlog_move_page_contents() in regard to initialization of writebuf.
Interestingly enough, the discrepancy exists since these functions
appeared with c11453ce0, and I can't see what justified adding the
initialization inside hash_xlog_move_page_contents() only.
So I think that if this doesn't affect performance, having aligned coding
(writebuf initialized in both functions) is better.

> 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).
>
> How do you think?

I can confirm that the test case proposed demonstrates what is expected
and the duration increase is tolerable, as to me.

Best regards,
Alexander



pgsql-hackers by date:

Previous
From: Alena Rybakina
Date:
Subject: Re: POC, WIP: OR-clause support for indexes
Next
From: Gabriele Bartolini
Date:
Subject: Re: Extend pgbench partitioning to pgbench_history