Horton

Re: Is this a problem in GenericXLogFinish()?

Amit Kapila <amit.kapila16@gmail.com>

View thread View on postgr.es
From: Amit Kapila <amit.kapila16@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Robert Haas <robertmhaas@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Alexander Lakhin <exclusion@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers@postgresql.org
Date: 2023-10-28T10:15:13Z
Lists: pgsql-hackers 
On Fri, Oct 27, 2023 at 5:45 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Thu, Oct 26, 2023 at 09:40:09AM -0400, Robert Haas wrote:
> > 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.
>
> Okay..
>
> > 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.
>
> Hmm.  So my question is: do we need the cleanup lock on the write
> buffer even if there are no tuples, and even if primary bucket and the
> write bucket are the same?
>

Yes, we need it to exclude any concurrent in-progress scans that could
return incorrect tuples during bucket squeeze operation.

-- 
With Regards,
Amit Kapila.

Commits

  1. Fix inconsistency with replay of hash squeeze record for clean buffers

  2. Set LSN for wbuf in _hash_freeovflpage() iff wbuf is modified.

  3. Fix an uninitialized access in hash_xlog_squeeze_page().

  4. Use REGBUF_NO_CHANGE at one more place in the hash index.

  5. Assert that buffers are marked dirty before XLogRegisterBuffer().

  6. Fix bug in GenericXLogFinish().

  7. Improve hash index bucket split behavior.