From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Is this a problem in GenericXLogFinish()? |
Date: | 2023-10-26 07:31:19 |
Message-ID: | ZToVxyLSVUisFPp0@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-10-26 07:39:26 | Re: pg_upgrade and logical replication |
Previous Message | Xiang Gao | 2023-10-26 07:28:35 | RE: CRC32C Parallel Computation Optimization on ARM |