Re: Is this a problem in GenericXLogFinish()?

On Thu, Oct 26, 2023 at 3:31 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> 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?

Read the comments for _hash_squeezebucket. Particularly, note this part:

* Try to squeeze the tuples onto pages occurring earlier in the
* bucket chain in an attempt to free overflow pages. When we start
* the "squeezing", the page from which we start taking tuples (the
* "read" page) is the last bucket in the bucket chain and the page
* onto which we start squeezing tuples (the "write" page) is the
* first page in the bucket chain. The read page works backward and
* the write page works forward; the procedure terminates when the
* read page and write page are the same page.

Because of this, it is possible for bucketbuf, prevbuf, and wbuf to be
the same (your first scenario) but the second scenario you mention
(nextbuf == wbuf) should be impossible.

It seems to me that maybe we shouldn't even be registering wbuf or
doing anything at all to it if there are no tuples that need moving.
That would also require some adjustment of the redo routine.

--
Robert Haas
EDB: http://www.enterprisedb.com