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 ZToVxyLSVUisFPp0@paquier.xyz
Whole thread Raw
In response to Re: Is this a problem in GenericXLogFinish()?  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Is this a problem in GenericXLogFinish()?
List pgsql-hackers
On Wed, Oct 25, 2023 at 10:06:23PM -0700, Jeff Davis wrote:
> Thank you for the report! I was able to reproduce and observe that the
> buffer is not marked dirty.
>
> The call (hashovfl.c:671):
>
>   XLogRegisterBuffer(1, wbuf, REGBUF_STANDARD)
>
> is followed unconditionally by:
>
>   PageSetLSN(BufferGetPage(wbuf), recptr)
>
> so if the Assert were not there, it would be setting the LSN on a page
> that's not marked dirty. Therefore I think this is a bug, or at least
> an interesting/unexpected case.
>
> Perhaps the registration and the PageSetLSN don't need to happen when
> nitups==0?

Hmm.  Looking at hash_xlog_squeeze_page(), it looks like wbuf is
expected to always be registered.  So, you're right here: it should be
OK to be less aggressive with setting the page LSN on wbuf if ntups is
0, but there's more to it?  For example, it is possible that
bucketbuf, prevbuf and wbuf refer to the same buffer, causing
is_prim_bucket_same_wrt and is_prev_bucket_same_wrt to be both true.
Particularly, if nextbuf and wbuf are the same buffers, we finish by
registering twice the same buffer with two different IDs to perform
the tuple insertion and the opaque area updates in two steps.  And
that's..  Err..  not really necessary?  I mean, as far as I read this
code you could just reuse the buffer registered at ID 1 and update its
opaque area if is_prim_bucket_same_wrt is true?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Xiang Gao
Date:
Subject: RE: CRC32C Parallel Computation Optimization on ARM
Next
From: Michael Paquier
Date:
Subject: Re: pg_upgrade and logical replication