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

From Michael Paquier
Subject Re: Is this a problem in GenericXLogFinish()?
Date
Msg-id Zg99dfJ5t6k1wcB1@paquier.xyz
Whole thread Raw
In response to Re: Is this a problem in GenericXLogFinish()?  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Is this a problem in GenericXLogFinish()?
RE: Is this a problem in GenericXLogFinish()?
Re: Is this a problem in GenericXLogFinish()?
List pgsql-hackers
On Wed, Feb 07, 2024 at 06:42:21PM +0900, Michael Paquier wrote:
> On Wed, Feb 07, 2024 at 02:08:42PM +0530, Amit Kapila wrote:
> > Thanks for the report and looking into it. Pushed!
>
> Thanks Amit for the commit and Kuroda-san for the patch!

I have been pinged about this thread and I should have looked a bit
closer, but wait a minute here.

There is still some divergence between the code path of
_hash_freeovflpage() and the replay in hash_xlog_squeeze_page() when
squeezing a page: we do not set the LSN of the write buffer if
(xlrec.ntups <= 0 && xlrec.is_prim_bucket_same_wrt &&
!xlrec.is_prev_bucket_same_wrt) when generating the squeeze record,
but at replay we call PageSetLSN() on the write buffer and mark it
dirty in this case.  Isn't that incorrect?  It seems to me that we
should be able to make the conditional depending on the state of the
xl_hash_squeeze_page record, no?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Statistics Import and Export
Next
From: Bharath Rupireddy
Date:
Subject: Re: LogwrtResult contended spinlock