RE: Is this a problem in GenericXLogFinish()?
Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
From: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
To: 'Amit Kapila' <amit.kapila16@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, 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" <pgsql-hackers@postgresql.org>
Date: 2023-11-13T05:47:26Z
Lists: pgsql-hackers
Attachments
- fix_hash_squeeze_wal_5.patch (application/octet-stream) patch
Dear Amit,
Thanks for reviewing! PSA new version patch.
> > > Next we should add some test codes. I will continue considering but please
> post
> > > anything
> > > If you have idea.
> >
> > And I did, PSA the patch. This patch adds two parts in hash_index.sql.
> >
> > In the first part, the primary bucket page is filled by live tuples and some
> overflow
> > pages are by dead ones. This leads removal of overflow pages without moving
> tuples.
> > HEAD will crash if this were executed, which is already reported on hackers.
> >
>
> +-- And do CHECKPOINT and vacuum. Some overflow pages will be removed.
> +CHECKPOINT;
> +VACUUM hash_cleanup_heap;
>
> Why do we need CHECKPOINT in the above test?
CHECKPOINT command is needed for writing a hash pages to disk. IIUC if the command
is omitted, none of tuples are recorded to hash index *file*, so squeeze would not
be occurred.
You can test by 1) restoring changes for hashovfl.c then 2) removing CHECKPOINT
command. Server crash would not be occurred.
> > The second one tests a case (ntups == 0 && is_prim_bucket_same_wrt ==
> false &&
> > is_prev_bucket_same_wrt == true), which is never done before.
> >
>
> +-- Insert few tuples, the primary bucket page will not satisfy
> +INSERT INTO hash_cleanup_heap SELECT 1 FROM generate_series(1, 50) as i;
>
> What do you mean by the second part of the sentence (the primary
> bucket page will not satisfy)?
I meant to say that the primary bucket page still can have more tuples. Maybe I
should say "will not be full". Reworded.
> Few other minor comments:
> =======================
> 1. Can we use ROLLBACK instead of ABORT in the tests?
Changed. IIRC they have same meaning, but it seems that most of sql files have
"ROLLBACK".
> 2.
> - for (i = 0; i < nitups; i++)
> + for (int i = 0; i < nitups; i++)
>
> I don't think there is a need to make this unrelated change.
Reverted. I thought that the variable i would be used only when nitups>0 so that
it could be removed, but it was not my business.
> 3.
> + /*
> + * A write buffer needs to be registered even if no tuples are added to
> + * it to ensure that we can acquire a cleanup lock on it if it is the
> + * same as primary bucket buffer or update the nextblkno if it is same
> + * as the previous bucket buffer.
> + */
> + else if (xlrec.is_prim_bucket_same_wrt || xlrec.is_prev_bucket_same_wrt)
> + {
> + uint8 wbuf_flags;
> +
> + Assert(xlrec.ntups == 0);
>
> Can we move this comment inside else if, just before Assert?
Moved.
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
Commits
-
Fix inconsistency with replay of hash squeeze record for clean buffers
- f56a9def71bb 17.0 landed
-
Set LSN for wbuf in _hash_freeovflpage() iff wbuf is modified.
- aa5edbe379d6 17.0 landed
-
Fix an uninitialized access in hash_xlog_squeeze_page().
- f66fcc5cd616 17.0 landed
-
Use REGBUF_NO_CHANGE at one more place in the hash index.
- 861f86beea1c 17.0 landed
-
Assert that buffers are marked dirty before XLogRegisterBuffer().
- 00d7fb5e2e39 17.0 landed
-
Fix bug in GenericXLogFinish().
- 04f0baa85865 11.22 landed
- 6dbd01b9fdad 12.17 landed
- 469d367bee2f 13.13 landed
- 6615bb95af2d 14.10 landed
- b9bb02620d4b 15.5 landed
- b8963e8a2854 16.1 landed
- ef74c7197c04 17.0 landed
-
Improve hash index bucket split behavior.
- 6d46f4783efe 10.0 cited