outdated comment in table_tuple_update definition
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t51020psql -h localhost -U postgresBuilt from patchset v2 (message #2), July 27, 2026 at 10:18 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t51020_2 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t51020_2 && git checkout t51020_2Patchset v2 (message #2) is on t51020_2
Hello
I noticed that the comment for the table_tuple_update function (src/include/access/tableam.h) describes the update_indexes parameter as boolean:
* update_indexes - in success cases this is set to true if new index entries
* are required for this tuple
Although this parameter is an enum of three values.
I found that the parameter type was changed by commit 19d8e23 (Ignore BRIN indexes when checking for HOT updates), but the comment was not updated. Looks like oversight.
* update_indexes - in successful cases, used to determine which index types
* require new index entries for this tuple
Something like this?
regards, Sergei
On 6 Feb 2025, at 20:00, Sergei Kornilov <sk@zsrv.org> wrote:
I found that the parameter type was changed by commit 19d8e23 (Ignore BRIN indexes when checking for HOT updates), but the comment was not updated. Looks like oversight.
I agree with your analysis, unless objected to I'll apply the attached in
shortly to update the documentation.
--
Daniel Gustafsson
On Fri, Feb 7, 2025 at 3:08 AM Daniel Gustafsson <daniel@yesql.se> wrote:
On 6 Feb 2025, at 20:00, Sergei Kornilov <sk@zsrv.org> wrote:
I found that the parameter type was changed by commit 19d8e23 (Ignore BRIN indexes when checking for HOT updates), but the comment was not updated. Looks like oversight.
I agree with your analysis, unless objected to I'll apply the attached in
shortly to update the documentation.
+ * update_indexes - in successful cases this indicates the index types
+ * which require new index entries for this tupleAFAIK, summarising indexes may not necessarily always need a new
entry. So the following sentence looks more accurate
in successful cases, this indicates the types of indexes (summarising
vs non-summarising) which need an update based on this tuple. The text
in the parenthese would clarify "index types", but if it's too
verbose, it may be omitted.
--
Best Wishes,
Ashutosh Bapat