Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 43 additions & 0 deletions .clangd
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
Diagnostics:
MissingIncludes: None
Comment on lines +1 to +2

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This .clangd file is personal editor/LSP tooling configuration and should not be part of a patch destined for pgsql-hackers/commitfest. Per PostgreSQL patch hygiene, a patch must be a minimal diff containing only what the stated change requires; committing local IDE/tooling config (this file, plus .gdbinit and pg-aliases.sh in this same change) is unrelated churn and a reliable rejection reason. The PostgreSQL tree does not carry .clangd. If you need it locally, put it in .git/info/exclude or your global gitignore rather than committing it. Remove this file from the patch.

Also note the hardcoded relative include path -I../../../../src/include (line 43) is brittle and workstation/subdirectory-specific, which further confirms this is a local artifact, not a tree-wide config.

Comment on lines +1 to +2

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file should not be committed to the repository. The project's root .gitignore explicitly states: "Auxiliary files from local workflows, your preferred editor, etc. should be ignored locally using $GIT_DIR/info/exclude or ~/.gitexclude." .clangd is a personal, editor/tooling-local config for the clangd language server and is unrelated to the actual code change in this patch (the buffer/vacuum work). Including it (along with the other added local files .gdbinit and pg-aliases.sh) violates the minimal-diff discipline and will be rejected on pgsql-hackers. Remove it from the patch and add it to your local git exclude instead.

Additionally, note the paths are developer-specific: CompilationDatabase: build/ and -I../../../../src/include assume a particular out-of-tree build layout that will not hold for other contributors, further confirming this is not a shareable, tree-wide file.

Comment on lines +1 to +2

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This .clangd file (along with .gdbinit and pg-aliases.sh added in this change) is a developer-local IDE/editor artifact and must not be committed to the tree. In a patch destined for pgsql-hackers/commitfest, personal tooling config is unrelated to the stated purpose (the HOT indexed updates work) and will be an immediate rejection: it is not minimal, it pollutes the repo root, and it encodes one contributor's environment (paths, compiler flags, project-specific breakpoint line numbers). PostgreSQL keeps editor config out of the tree and leaves it to each developer's dotfiles. Remove this file from the patch.

Comment on lines +1 to +2

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This .clangd file, along with .gdbinit and pg-aliases.sh, is a personal developer-environment artifact and does not belong in a PostgreSQL patch. Committing editor/LSP configuration into the source tree violates the minimal-diff discipline: the patch should contain only the changes required for the stated purpose (the HOT indexed updates work). These files will cause needless conflicts, pollute every developer's tree, and would be immediately rejected on pgsql-hackers. Remove it from the commit (and add it to your local git excludes / .git/info/exclude instead).

Comment on lines +1 to +2

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire file should not be committed. It is a personal editor/LSP configuration, not part of PostgreSQL's build or source. The project's own top-level .gitignore documents this policy explicitly: "Auxiliary files from local workflows, your preferred editor, etc. should be ignored locally using $GIT_DIR/info/exclude or ~/.gitexclude." A patch destined for pgsql-hackers/commitfest must be a minimal diff; unrelated tooling/config files like this are a top rejection reason. Please drop this file from the patch and ignore it locally instead. (high confidence)

Comment on lines +1 to +2

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This .clangd file is per-developer editor/LSP tooling and should not be committed to the tree. Upstream PostgreSQL does not carry .clangd, and this same PR git-ignores .vscode/ and .idea/ in .github/.gitignore for exactly this reason. A patch posted to pgsql-hackers carrying personal editor config will be rejected. Add .clangd to .gitignore instead of committing it. (high confidence)

Comment on lines +1 to +2

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This .clangd file is personal editor/LSP configuration and does not belong in a patch destined for pgsql-hackers. PostgreSQL does not commit per-developer tooling to the tree root (the same applies to the sibling .gdbinit and pg-aliases.sh in this change). A patch that adds unrelated local tooling will be rejected on the -hackers list: it violates the minimal-diff rule and bundles more than one thing. If you want this locally, keep it out of version control (e.g. via a global/personal gitignore) rather than committing it. Recommend dropping this file from the patch entirely.

Confidence: high.

Comment on lines +1 to +2

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire file should not be part of the patch. PostgreSQL's own top-level .gitignore states the policy explicitly: "Auxiliary files from local workflows, your preferred editor, etc. should be ignored locally using $GIT_DIR/info/exclude or ~/.gitexclude." A .clangd file is precisely such an editor/tooling artifact (as are the companion .gdbinit and pg-aliases.sh files in this changeset). Committing personal IDE configuration is unrelated churn that will draw an immediate rejection on pgsql-hackers. Keep it in a local exclude instead of tracking it. [high confidence]

Comment on lines +1 to +2

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This .clangd file is personal, developer-local editor tooling that must not be part of a PostgreSQL patch. It is unrelated to the actual change (the HOT indexed updates / buffer manager work in the other files) and does more than the patch's stated purpose. A few concrete problems:

  1. It is not minimal-diff: adding a per-developer LSP config alongside .gdbinit and pg-aliases.sh is exactly the kind of unrelated scaffolding that gets a patch rejected on -hackers. The tree has no .clangd, and adding one imposes one contributor's editor setup on everyone.
  2. It hardcodes a relative include path -I../../../../src/include, which only resolves from a specific nested subdirectory and is meaningless at the repository root where this file lives.
  3. -DPGDLLIMPORT= silently blanks out PGDLLIMPORT, which would hide exactly the Windows/MSVC export-annotation issues the project cares about (a footgun for anyone relying on clangd diagnostics).

If local clangd config is desired, it belongs in the developer's own environment (or .git/info/exclude / a personal gitignore), not committed to the tree. Recommend dropping this file (and .gdbinit, pg-aliases.sh) from the patch entirely.

Comment on lines +1 to +2

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This .clangd file should not be committed. It is an editor/language-server auxiliary file, and the repository's top-level .gitignore explicitly documents the policy: "Auxiliary files from local workflows, your preferred editor, etc. should be ignored locally using $GIT_DIR/info/exclude or ~/.gitexclude." This change is also unrelated to the buffer-manager work in the rest of the patch (bufmgr.c/freelist.c/localbuf.c) and bundles personal tooling into a functional patch. A patch posted to pgsql-hackers containing personal IDE config will be rejected as out-of-scope. Remove it from the commit and exclude it locally instead.

Comment on lines +1 to +2

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This .clangd is personal editor scaffolding, not part of the HOT-indexed-updates feature. The top-level .gitignore explicitly directs auxiliary/editor files to be ignored locally via $GIT_DIR/info/exclude, not committed. Including it in a commitfest-bound PR violates the minimal-diff / one-logical-change discipline and will draw rejection on -hackers. It also hardcodes a relative include path (-I../../../../src/include) that only resolves from one specific subdirectory depth, so it is not even generally correct. Please drop it from the patch.

Comment on lines +1 to +2

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[high confidence] This is personal developer-environment config and must not be committed to a patch destined for pgsql-hackers/commitfest. The repository's top-level .gitignore explicitly directs such files to a local $GIT_DIR/info/exclude or ~/.gitexclude. Beyond that policy, -I../../../../src/include and CompilationDatabase: build/ assume a fixed working-directory depth and build layout, so this is brittle and environment-specific. Drop this file from the patch.

Comment on lines +1 to +2

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Editor-local config that should not be committed. The repository's own .gitignore header states: "Auxiliary files from local workflows, your preferred editor, etc. should be ignored locally using $GIT_DIR/info/exclude or ~/.gitexclude." A .clangd is exactly such a file and, in a patch headed for pgsql-hackers, violates the minimal-diff discipline. Keep it out of the tree.

Comment on lines +1 to +2

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire group of files (.clangd, .gdbinit, flake.nix, shell.nix, pg-aliases.sh) is personal developer/editor/debugger/Nix tooling that is unrelated to the actual change in this update (the pg_buffercache / NUMA clock-sweep partitioning work in freelist.c, buf_init.c, bufmgr.c, etc.). PostgreSQL's own .gitignore says so explicitly: "Auxiliary files from local workflows, your preferred editor, etc. should be ignored locally using $GIT_DIR/info/exclude or ~/.gitexclude." Committing this scaffolding violates the minimal-diff discipline, is not part of any pgsql-hackers patch, and will cause needless merge conflicts for other contributors. These files should be removed from the patch and kept out of tree via a local/global gitignore instead.

Comment on lines +1 to +2

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.clangd is a personal editor configuration that assumes a specific working directory and build layout (build/ for the compilation database, -I. and -I../../../../src/include). It is unrelated to the PR's subject and will not match other contributors' layouts. Developer-specific editor config should not be committed to the PostgreSQL tree; keep it in a local, git-ignored location.

InlayHints:
Enabled: true
ParameterNames: true
DeducedTypes: true
CompileFlags:
CompilationDatabase: build/ # Search build/ directory for compile_commands.json

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This .clangd LSP config is a personal editor artifact and should not be committed, per the repository's own root .gitignore policy (lines 1-3: "Auxiliary files from ... your preferred editor ... should be ignored locally using $GIT_DIR/info/exclude or ~/.gitexclude"). It is out of scope for a pgsql-hackers/commitfest patch and pollutes the diff. [high confidence]

Additionally the config is not portable to other contributors: CompilationDatabase: build/ and -I../../../../src/include encode one developer's build layout and assumed working directory (no build/ compilation database exists or is generated at a standard tracked location in this tree). As a repo-root config it silently applies -DDEBUG, -DLOCAL, -DPGDLLIMPORT= and other flags to every file opened in any clangd-enabled editor, which can mask real diagnostics (e.g. defining PGDLLIMPORT to empty hides Windows export-annotation issues) for everyone who clones the repo. Recommend removing this file from the change.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-ASCII smart quote / em-dash characters appear in the added comments (this line uses —; .gdbinit also uses — in its header). PostgreSQL sources and diffs must be ASCII only -- no smart quotes, em-dashes, or ellipsis characters. Replace with a plain hyphen if these files are kept at all (though the primary recommendation is to drop both files). [high confidence]

Comment on lines +7 to +8

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a per-developer IDE environment file (CompilationDatabase: build/, personal flags like -DLOCAL, -O2, -std=c11, and hard-coded relative includes -I. / -I../../../../src/include). Committing it imposes one contributor's local layout on everyone and is unrelated to any functional change in this series — it would be flagged as non-minimal diff on pgsql-hackers. Such IDE/build artifacts belong in a personal, git-ignored config, not the source tree. [high confidence]

Remove: [ -Werror ]
Add:
- -DDEBUG
- -DLOCAL
- -DPGDLLIMPORT=
- -DPIC
- -O2
- -Wall
- -Wcast-function-type
- -Wconversion
- -Wdeclaration-after-statement
- -Wendif-labels
- -Werror=vla
- -Wextra
- -Wfloat-equal
- -Wformat-security
- -Wimplicit-fallthrough=3
- -Wmissing-format-attribute
- -Wmissing-prototypes
- -Wno-format-truncation
- -Wno-sign-conversion
- -Wno-stringop-truncation
- -Wno-unused-const-variable
- -Wpointer-arith
- -Wshadow
- -Wshadow=compatible-local
- -fPIC
- -fexcess-precision=standard
- -fno-strict-aliasing
- -fvisibility=hidden
- -fwrapv
- -g
- -std=c11
- -I.
- -I../../../../src/include

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This include path is almost certainly wrong for a .clangd placed at the repository root. Relative -I flags added via CompileFlags.Add are resolved relative to the compile command's directory (the build/ dir set above) or the source file's directory, not the repo root. Going up four levels (../../../../) from anywhere at/under the repo root lands outside the tree and never resolves to <repo>/src/include. The ../../../../ prefix looks copy-pasted from a deeply nested subdirectory's build flags. Since src/include sits directly under the root, use a root-relative path instead. (Impact is limited to the author's own clangd header resolution, and MissingIncludes: None suppresses the resulting diagnostics, hence low severity.)

Suggested change
- -I../../../../src/include
- -Isrc/include

Comment on lines +42 to +43

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These -I paths are resolved by clangd relative to each translation unit's own directory, not the repo root. -I../../../../src/include only points at <repo>/src/include for source files that happen to sit exactly four directories deep (e.g. src/backend/storage/buffer/*.c). For files at other depths — e.g. contrib/pg_buffercache/*.c (two deep) or top-level files — it resolves to a non-existent directory, so clangd will fail to find core headers and produce spurious diagnostics for those TUs. Since CompilationDatabase: build/ already supplies correct per-file -I flags from compile_commands.json, these hardcoded relative includes are both fragile and redundant; consider dropping them (or using an absolute/${workspaceFolder}-style path) so the fallback works uniformly across the tree.

Comment on lines +42 to +43

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The -I paths here are hard-coded to a single fixed source layout. -I. plus a fixed -I../../../../src/include only resolves correctly when clangd is invoked from a directory exactly four levels below src/include (e.g. a specific per-file build subdir), and is wrong for files at the repo root or at other depths. Since a compile_commands.json from the meson build/ directory (already referenced via CompilationDatabase: build/) provides the correct per-file include flags, these manual -I entries are both incorrect and redundant. This is another reason this file should not be committed.

Comment on lines +42 to +43

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The include path -I../../../../src/include is hardcoded relative to a specific nested subdirectory depth. Combined with -I., this only resolves correctly from a directory exactly four levels deep in the tree, so it is broken for a repo-root .clangd and is inherently non-portable across the tree layout. This reinforces that the file is a machine-specific artifact that should not be committed.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hardcoded relative include path -I../../../../src/include only resolves for source files nested exactly four directories deep (e.g. contrib/foo/); it is wrong for top-level src/backend/... files and breaks clangd indexing there. Since CompilationDatabase: build/ already supplies per-file compile flags from compile_commands.json, this fragile manual -I is both redundant and incorrect and should be dropped. (moderate confidence)

Comment on lines +42 to +43

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The relative include path -I../../../../src/include is fragile and wrong for a config file at the repository root. From the repo root, the source headers live at src/include, not four directories up. This hardcoded ../../../../ prefix assumes clangd is being invoked from a deeply nested build subdirectory, which won't hold generally and makes header resolution non-portable across checkout locations. If this file is kept at all, the path should be -Isrc/include (repo-root relative) or an absolute path.

Confidence: high.

Comment on lines +42 to +43

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This hardcoded relative include path is fragile. Since .clangd lives at the repository root and CompilationDatabase: build/ is set, real include paths should come from build/compile_commands.json. -I../../../../src/include only resolves for a source file located exactly four directory levels below the repo root; for files at any other depth it points outside the tree (or nowhere), so it either does nothing or resolves to an unintended directory. Likewise -I. is resolved relative to each translation unit's directory, not the repo root, so it does not reliably add the source root. Recommend dropping both hardcoded -I entries and relying on the compilation database, or using an absolute path.

Comment on lines +42 to +43

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The include path -I../../../../src/include is hardcoded to a relative depth that only resolves when clangd is invoked from one specific subdirectory nesting (four levels below the tree root). Combined with CompilationDatabase: build/, this reflects a single developer's local layout and won't work generally. This further confirms the file is a personal, non-portable local artifact that does not belong in the shared repository.

Comment on lines +42 to +43

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-I../../../../src/include encodes a single fixed directory depth, so it only resolves correctly from a source file nested exactly four levels below the repo root; clangd diagnostics will be inconsistent (and includes unresolved) for files at other depths. Since CompilationDatabase: build/ is already configured and a compile_commands.json carries per-file include paths, this hardcoded relative include is both redundant and misleading -- drop it and rely on the compilation database.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hardcoded relative include paths -I. and -I../../../../src/include assume clangd is invoked from a specific directory depth and will produce incorrect diagnostics from other locations. Since CompilationDatabase: build/ already supplies the real per-file include flags from compile_commands.json, these fixed -I entries are redundant and fragile.

Comment on lines +42 to +43

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is developer-local editor configuration and, together with .gdbinit, flake.nix, and shell.nix (plus sibling additions like pg-aliases.sh, paper/Makefile, and the fork-specific .github/workflows/*), it is personal/dev-environment scaffolding unrelated to the HOT-indexed-updates feature. A patch destined for pgsql-hackers/commitfest must be a minimal diff containing only what the feature requires; committing per-developer tooling into the source tree is a top rejection reason. Keep these in a local branch or add them to .gitignore rather than including them in the reviewable patch. One concrete content note: the -I../../../../src/include relative include path assumes a specific per-directory build layout and will not resolve from the repo root, which further confirms this is a hand-tuned local file.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The include path uses a fixed relative depth (../../../../src/include) that only resolves from one specific build subdirectory. It will silently fail to find headers when clangd is launched from the repo root or any other depth, defeating the purpose of the config. If this file were to stay (it should not; see the top-level comment), prefer -Isrc/include relative to the project root or rely entirely on compile_commands.json.

156 changes: 156 additions & 0 deletions .gdbinit
Original file line number Diff line number Diff line change
@@ -0,0 +1,156 @@
# HOT Indexed Updates — GDB breakpoints for code review

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire file is a personal debugging aid and must be removed from the patch. Committing a .gdbinit violates PostgreSQL patch hygiene (minimal diff) and will be an automatic rejection on -hackers. It is also a real footgun: GDB auto-loads .gdbinit from the current working directory, so shipping one in the repository root causes arbitrary debugger commands to execute for anyone who launches gdb in a checkout (local code-execution vector). This is not tracked in .gitignore, so it should not be committed at all. The co-added .clangd and pg-aliases.sh are the same class of out-of-scope developer artifacts and should likewise be dropped from the patch.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire file (.gdbinit), together with the sibling additions .clangd and pg-aliases.sh, is a personal developer debugging/environment artifact and does not belong in a PostgreSQL patch. Patches destined for pgsql-hackers/commitfest must be minimal and contain only the changes required by the stated purpose; per-developer scratch files are a top rejection reason and cause needless merge conflicts. The project's .gitignore explicitly states such auxiliary files 'should be ignored locally using $GIT_DIR/info/exclude or ~/.gitexclude', not committed. Additionally, a .gdbinit in the repo root is a footgun: GDB auto-loads ./.gdbinit from the working directory, so any developer launching gdb in the checkout silently executes these commands. Please drop this file (and its siblings) from the patch.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The header (and several other comment lines) use a non-ASCII em-dash character ('—'), which violates the project's ASCII-only rule for source and diffs. Use a plain ASCII hyphen/dash instead.

Suggested change
# HOT Indexed Updates — GDB breakpoints for code review
+# HOT Indexed Updates - GDB breakpoints for code review

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The em-dash (U+2014) violates the ASCII-only rule for source and diffs. If this file were to be kept at all, use an ASCII hyphen. (More fundamentally, the whole file should not be committed.)

Confidence: high.

Suggested change
# HOT Indexed Updates — GDB breakpoints for code review
# HOT Indexed Updates - GDB breakpoints for code review

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire .gdbinit is a personal debugging artifact and must not be committed. For a patch destined for pgsql-hackers/commitfest, the minimal-diff rule is a hard gate: the tree should contain only changes required for the stated functional purpose. A debugger config in the repository root is a top rejection reason and pollutes the root for every other developer. I confirmed .gitignore does not ignore it, so it would actually be committed. The co-added .clangd and pg-aliases.sh are the same class of personal tooling and should likewise be dropped (gitignore them locally instead). (high confidence)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-ASCII characters (em dash U+2014) appear in the header and inline comments, violating the ASCII-only rule for source and diffs. If any of this were retained it would fail hygiene checks; use a plain hyphen - instead. (high confidence)

Suggested change
# HOT Indexed Updates — GDB breakpoints for code review
+# HOT Indexed Updates - GDB breakpoints for code review

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This repository-root .gdbinit is a personal debugging artifact and does not belong in a patch destined for pgsql-hackers/commitfest (minimal-diff / YAGNI hygiene). Beyond the unrelated-tooling problem (it is bundled with pg-aliases.sh), it is a real footgun: gdb auto-sources a .gdbinit in the current directory when launched from the project root (subject to auto-load safe-path settings), so committing this can silently alter another developer's debugging session by setting 30+ breakpoints they never asked for. Remove it from the patch and add .gdbinit to .gitignore instead.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ASCII-only is required in source/diffs. This line (and the section headers below, e.g. lines 15, 38, 52, ...) use a Unicode em-dash (U+2014 —) rather than a plain hyphen. Replace every em-dash with - / --.

Suggested change
# HOT Indexed Updates — GDB breakpoints for code review
# HOT Indexed Updates -- GDB breakpoints for code review

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This .gdbinit is a personal developer debugging artifact and should not be committed. It violates the minimal-diff discipline (unrelated scaffolding with no functional value to the patch), and it is a footgun: GDB auto-loads a .gdbinit from the current working directory, so shipping one in the repo root can silently alter debugging behavior for anyone who runs gdb from the checkout. Note that .github/docs/pristine-master-policy.md and pg-aliases.sh already treat .gdbinit as local debugger config, yet it is not in the root .gitignore. Remove it from the patch and keep it local/untracked (add to .gitignore if needed).

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire file is a developer-local debugging artifact and must not be committed. The repository's own .gitignore states at the top: "Auxiliary files from local workflows, your preferred editor, etc. should be ignored locally using $GIT_DIR/info/exclude or ~/.gitexclude." A .gdbinit at the repo root is exactly such a file. Committing it violates the minimal-diff / one-logical-change discipline and would be rejected on pgsql-hackers as unrelated churn. Remove it from the change set and add it to your local excludes instead.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire file should not be committed. .gdbinit at the repo root is a personal developer debugging artifact, not part of a PostgreSQL patch. It is also a footgun/security hazard: GDB auto-loads .gdbinit from the current working directory (subject to auto-load safe-path), so committing it can silently execute debugger commands for anyone who runs gdb in this checkout. Keep this local (developer's global gdbinit or a gitignored file) and drop it from the patch. This will otherwise draw an immediate rejection on -hackers and violates the minimal-diff discipline.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-ASCII em-dash character ('—') violates the ASCII-only-in-source discipline. This appears in the header line and repeatedly throughout the file (e.g., subsystem headers). Since the file should be removed entirely this is moot, but if any comparable file were kept it must use ASCII ('-' or '--').

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire file is a personal developer debugging artifact, not part of any feature. A patch destined for pgsql-hackers/commitfest must be minimal and contain only what the change requires. Committing a top-level .gdbinit (alongside .clangd and pg-aliases.sh) pollutes the tree, makes the patch "do more than one thing," and is an immediate rejection reason. It also has security implications: a .gdbinit in a working directory auto-executes GDB commands, and shipping one in-tree is a footgun. Remove it from the patch and keep it local (e.g. via a personal, un-tracked gitignore).

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The header uses a non-ASCII em-dash. PostgreSQL sources are ASCII-only (no smart quotes, em-dashes, or ellipsis characters). If this file were kept at all it must use a plain ASCII hyphen.

Suggested change
# HOT Indexed Updates — GDB breakpoints for code review
# HOT Indexed Updates - GDB breakpoints for code review

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-ASCII em-dash characters (U+2014 "—") are used throughout the comments here, violating the project's ASCII-only rule for source and diffs. If this file were to be kept (it should not), these would need to be replaced with an ASCII hyphen/dash.

Severity: low confidence — minor hygiene issue, secondary to the file not belonging in the patch at all.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire file must not be committed to a PostgreSQL patch submission. It is a personal debugging artifact that violates the minimal-diff discipline (a top rejection reason on pgsql-hackers). It is also a footgun: GDB auto-loads .gdbinit from the current directory, so anyone invoking gdb from the repo root will silently execute these breakpoint commands. Worse, verification shows this is orphaned scaffolding: the referenced helper functions (heap_hot_indexed_create_tuple, heap_hot_indexed_tuple_size, heap_hot_indexed_serialize_bitmap, heap_xlog_indexed_update, the HEAP_INDEXED_UPDATED flag, etc.) do NOT exist anywhere in this tree, and none of the HOT-indexed-update code they target is part of this changeset. Remove this file (keep it local, e.g. in a personal gitignore).

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This .gdbinit is a personal debugger artifact that must not be committed. The repository's own root .gitignore (lines 1-3) states policy explicitly: "Auxiliary files from local workflows, your preferred editor, etc. should be ignored locally using $GIT_DIR/info/exclude or ~/.gitexclude." A debugger config for one developer's session belongs in $GIT_DIR/info/exclude, not in a patch destined for pgsql-hackers/commitfest.

Beyond scope, this is a security footgun: GDB auto-loads .gdbinit from the current working directory, so any developer who runs gdb from the repo root silently executes its contents -- a well-known code-execution vector. It also defeats the auto-load safe-path protections GDB ships to warn against exactly this. [high confidence] Recommend removing this file from the change entirely.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire file is personal developer scaffolding and does not belong in a patch destined for pgsql-hackers/commitfest. It references a feature that is not present in this change: a codebase search confirms none of the heap_hot_indexed_* symbols (e.g. heap_hot_indexed_create_tuple, heap_hot_indexed_read_bitmap) nor XLOG_HEAP2_INDEXED_UPDATE / heap_xlog_indexed_update exist anywhere under src/. A .gdbinit tied to a nonexistent feature is dead weight that will draw immediate rejection on-list. This file (together with .clangd, pg-aliases.sh, flake.nix, shell.nix) should be kept out of the tree (e.g. via a personal/global gitignore), not committed.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file contains non-ASCII em-dash characters (U+2014 —) in multiple comment lines (lines 1, 15, 38, 52, 81, 98, 106, 117, 140, 148). PostgreSQL requires source and diffs to be ASCII-only (no smart quotes, em-dashes, or ellipsis characters). Replace each — with an ASCII - or --. (This is distinct from the file not belonging in the patch at all.)

Suggested change
# HOT Indexed Updates — GDB breakpoints for code review
+# HOT Indexed Updates -- GDB breakpoints for code review

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GDB auto-sources ./.gdbinit from the working directory (subject to auto-load safe-path). A committed .gdbinit that silently installs dozens of breakpoints -- most at hardcoded line numbers that don't match this tree -- is a footgun: a contributor debugging an unrelated issue will have execution halt at unexpected places or see breakpoint-resolution errors on startup. This is developer-local tooling that does not belong in a committable PostgreSQL patch; it should be kept out of the tree (e.g. via $GIT_DIR/info/exclude as the project's own .gitignore header recommends) rather than committed.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire file is developer-local debugging state that does not belong in a patch destined for pgsql-hackers. Beyond the minimal-diff objection, it is actively broken: the breakpoints hardcode absolute source line numbers (heapam.c:4019, pruneheap.c:1802, pruneheap.c:2936, etc.) and symbol names (heap_hot_indexed_create_tuple, heap_hot_search_buffer, ...) that do not exist in this tree. A codebase search for heap_hot_indexed_ returns zero matches, and the referenced heap/pruneheap changes are not part of this change set. These breakpoints point at nothing and will rot silently the moment the source shifts by a line. Recommend removing this file from the patch and keeping it in a personal, git-ignored location.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-ASCII characters (em-dash —) appear in this file. PostgreSQL requires ASCII-only in source and committed files.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This developer-only .gdbinit does not belong in a PostgreSQL patch and would be rejected on pgsql-hackers as unrelated noise. Worse, it is scaffolding for an unmerged feature: the breakpoints reference heap_hot_indexed_create_tuple, heap_hot_indexed_serialize_bitmap, heap_xlog_indexed_update, XLOG_HEAP2_INDEXED_UPDATE, and indexed_attrs (indexam.c) — none of which exist anywhere in this tree (verified via code search, zero matches). A source .gdbinit against today's binary will fail to set these breakpoints. Keep this in a developer's local, git-ignored environment, not in the source tree. [high confidence]

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-ASCII characters: these comment lines use em-dashes (U+2014 —) rather than ASCII. PostgreSQL requires ASCII-only in source and diffs (no smart quotes, em-dashes, or ellipses). Replace every — with an ASCII - (or -). This recurs on the section-header lines throughout the file (e.g. lines 15, 38, 52, 81, 98, 106, 117, 140, 148).

Suggested change
# HOT Indexed Updates — GDB breakpoints for code review
+# HOT Indexed Updates - GDB breakpoints for code review

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire file is unrelated to the PR's subject (the NUMA/pg_buffercache work in the other changed files). It is a personal debugging helper and should not be committed to the PostgreSQL tree. Bundling unrelated local tooling into a patch destined for pgsql-hackers is a top rejection reason.

Worse, these breakpoints target code that does not exist in this branch: the heap_hot_indexed_* symbols, heap_xlog_indexed_update, and the HOT-indexed paths in pruneheap.c/heapam.c/execIndexing.c are all absent from the tree (verified via search). The hardcoded file:line breakpoints (e.g. heapam.c:3210, pruneheap.c:1802) will silently drift and point at wrong lines. This file belongs to a different, unmerged feature branch and should be removed.

#
# Usage: gdb -x .gdbinit <postgres-binary>
Comment on lines +1 to +3

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This .gdbinit is a developer-local debugging artifact and does not belong in a PostgreSQL source patch. It is added alongside two other personal tooling files (.clangd, pg-aliases.sh), none of which are part of any functional change. Committing them violates the minimal-diff discipline (unrelated files are the top rejection reason on pgsql-hackers) and will pollute the tree root. Remove all three from the patch.

Worse, the file is orphaned from the feature it targets: the breakpoints reference a "HOT indexed updates" implementation that is NOT present in this tree. Symbols such as heap_hot_indexed_create_tuple, heap_hot_indexed_serialize_bitmap, heap_hot_indexed_tuple_size, heap_hot_indexed_read_bitmap, heap_xlog_indexed_update, and macros HEAP_INDEXED_UPDATED / XLOG_HEAP2_INDEXED_UPDATE exist ONLY inside this .gdbinit — a codebase search finds them nowhere else. GDB would reject those break commands at load time. This indicates a mis-scoped commit: the debug file was committed without (or ahead of) the feature it targets, which also breaks the atomic/bisectable-commit rule.

Comment on lines +1 to +3

ghost Jul 23, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire file is a personal debugging artifact and must not be committed to the PostgreSQL tree. GDB auto-loads .gdbinit from the working directory, so committing it is also a footgun (auto-executed setup for anyone building in this dir). Along with the sibling .clangd and pg-aliases.sh, this violates the minimal-diff rule: a patch destined for pgsql-hackers/commitfest must contain only the changes required by the stated feature. This file (and its siblings) should be moved to a personal/global ignore list or removed from the change set entirely.

Confidence: high.

# Or from gdb: source .gdbinit
Comment on lines +1 to +4

ghost Jul 27, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire file is a personal developer-tooling artifact (a GDB breakpoint script) and must not be committed to the PostgreSQL tree. It is added alongside two other local scratch files in this same change (.clangd, pg-aliases.sh), so the patch does more than one thing and pollutes the repository root -- an instant rejection on pgsql-hackers under the minimal-diff rule. Confirmed: .gdbinit is not listed in any .gitignore, so it was actively tracked rather than ignored. Worse, none of the code this file targets exists in the tree: a search for the referenced helpers (heap_hot_indexed_*) and the HEAP_INDEXED_UPDATED / XLOG_HEAP2_INDEXED_UPDATE symbols finds no matches anywhere except inside this file, and none of the files it references (heapam.c, heapam_indexscan.c, indexam.c, execIndexing.c, pruneheap.c, heapam_xlog.c) are part of this change. The file should be dropped from the commit entirely; if it must exist locally, put it in a personal global gitignore, not the repo. (high confidence)

Comment on lines +1 to +4

ghost Aug 3, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This .gdbinit is a personal debugging artifact and should not be part of a PostgreSQL contribution. It is not referenced by any build/test/gitignore infrastructure (confirmed: no references anywhere in the tree), is required by none of the actually-changed files (bufmgr/freelist/localbuf/pg_buffercache/pg_regress/pgindent/.clangd/pg-aliases.sh are all unrelated to HOT indexed updates), and placing an auto-loading .gdbinit at the repo root is a footgun: any developer running gdb in this directory silently gets these breakpoints (and gdb may refuse to auto-load or warn, depending on auto-load safe-path). Drop this file from the patch entirely.

Severity: high confidence.

#
# These breakpoints cover the major code paths introduced or modified by

ghost Jul 16, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ASCII-only is required in PostgreSQL source and diffs. This comment block uses non-ASCII em-dashes (e.g., "HOT Indexed Updates —", "returns Bitmapset" lines and the "—" separators throughout). Another reason this file cannot be committed as-is.

# the HOT indexed updates patch series. They are organized by subsystem
Comment on lines +6 to +7

ghost Jul 23, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Topic mismatch: this file's stated purpose is a "HOT Indexed Updates" feature, but that feature is not present in this change set (the actual modified files are buffer-manager code: bufmgr.c, freelist.c, localbuf.c, buf_internals.h, pg_buffercache). A search of the heap access code found none of the symbols referenced below (heap_hot_indexed_create_tuple, heap_xlog_indexed_update, heap_hot_indexed_serialize_bitmap, HEAP_INDEXED_UPDATED). The commit therefore bundles unrelated content and is neither atomic nor bisectable.

Confidence: high.

Comment on lines +6 to +7

ghost Oct 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire file targets a "HOT indexed updates" feature whose symbols do not exist anywhere in this tree. I verified that heap_hot_indexed_tuple_size, heap_hot_indexed_create_tuple, heap_hot_search_buffer's indexed-update variants, heap_xlog_indexed_update, and HEAP_INDEXED_UPDATED return zero matches under src/. The actual source change in this PR is buffer-cooling state (BUF_COOLED, BUF_COOLSTATE_HOT, StrategyCoolClaims) in bufmgr.c/freelist.c -- a completely different, unrelated feature. These breakpoints are orphaned scaffolding from a different patch series and would mislead or fail to resolve for anyone sourcing the file. This file should not be committed (and none of this developer-local tooling belongs in an upstream patch).

# to make it easy to enable/disable groups during debugging.
#
# Tip: to skip to a specific subsystem, disable all then enable selectively:
# disable breakpoints
# enable 1 2 3 # just the update-decision group

# =========================================================================
# 1. UPDATE DECISION — heap_update() HOT/HOT-indexed/non-HOT choice

ghost Jul 27, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-ASCII em-dash (U+2014) characters appear throughout the section headers (e.g. "HOT Indexed Updates — GDB breakpoints", "UPDATE DECISION — heap_update()"). PostgreSQL sources and diffs are required to be ASCII-only; use a plain hyphen/dash instead. Minor relative to the file not belonging in the tree at all, but noted for completeness. (high confidence)

Suggested change
# 1. UPDATE DECISION — heap_update() HOT/HOT-indexed/non-HOT choice
+# 1. UPDATE DECISION -- heap_update() HOT/HOT-indexed/non-HOT choice

ghost Jul 28, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-ASCII em-dash characters (U+2014) are used throughout the header comments (lines 1, 15, 38, 52, 81, 98, 106, 117, 140, 148). PostgreSQL sources must be ASCII-only - no em-dashes, smart quotes, or ellipsis characters. Replace — with an ASCII hyphen/dash. (Moot if the file is removed entirely, as recommended above.)

Suggested change
# 1. UPDATE DECISION — heap_update() HOT/HOT-indexed/non-HOT choice
+# 1. UPDATE DECISION - heap_update() HOT/HOT-indexed/non-HOT choice

ghost Aug 20, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-ASCII em-dash characters (U+2014) appear in the header and every section separator (e.g. "HOT Indexed Updates —", "UPDATE DECISION —"). PostgreSQL source policy requires ASCII-only in source and diffs. Even setting aside that the whole file should be removed, this content would fail source-hygiene checks.

Suggested change
# 1. UPDATE DECISION — heap_update() HOT/HOT-indexed/non-HOT choice
# 1. UPDATE DECISION - heap_update() HOT/HOT-indexed/non-HOT choice

# src/backend/access/heap/heapam.c
# =========================================================================

# Main entry: heap_update
break heapam.c:3210
Comment on lines +19 to +20

ghost Jul 15, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hardcoded file:line breakpoints are inaccurate and brittle. For example, heapam.c:3210 is labeled "Main entry: heap_update", but line 3210 is actually the variable declaration bool all_visible_cleared_new = false; inside the function body — not the function entry. Since heapam.c is heavily modified in this very change set, all such line-based breakpoints (4019, 4024, 4033, 4101, 4147, etc.) are already stale. Prefer function-name breakpoints; but ultimately this file should not be tracked in the repository at all.

ghost Jul 16, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Breakpoints anchored to hardcoded source line numbers (heapam.c:3210/4019/4024/4033/4101/4147, heapam_indexscan.c:182/250/297, indexam.c:299, execIndexing.c:370, pruneheap.c:1287/1802/1836/1863/2936) are inherently fragile: they silently drift as surrounding code changes and will land on the wrong statements. Since this file should not be committed at all (see above), this is moot, but even as a private aid, function-name breakpoints are far more robust than line-number ones.

Comment on lines +19 to +20

ghost Jul 19, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Line-number breakpoints are inherently fragile: they silently drift the moment any adjacent code changes. In fact heapam.c:3210 is not heap_update at all — in the current tree line 3210 is case TM_Ok: inside simple_heap_update's result switch. The embedded per-line annotations (e.g. 'Line 4019: pure HOT') are self-invalidating documentation of exactly the kind the project discourages. If this file were to be kept at all, breakpoints should be set by function name only.

Comment on lines +19 to +20

ghost Jul 23, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hardcoded file:line breakpoints are extremely fragile: they silently point at the wrong statement (or fail to resolve) after any edit to these files. Worse, these specific lines/symbols do not exist in the current tree - the referenced HOT-indexed functions and flag (heap_hot_indexed_*, heap_xlog_indexed_update, HEAP_INDEXED_UPDATED) were not found in src/backend/access/heap. These breakpoints reference code outside this change and are stale/meaningless here.

Confidence: high.

Comment on lines +19 to +20

ghost Jul 27, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Line-number breakpoints (e.g. heapam.c:3210, heapam.c:4019/4024/4033/4101/4147, heapam_indexscan.c:182/250/297, indexam.c:299, execIndexing.c:370, pruneheap.c:1287/1802/1836/1863/2936) are inherently fragile: any edit to those files silently shifts every line, so the comments asserting specific semantics ("Line 4019: pure HOT", "Line 4024: HOT indexed path") are unverifiable and become stale immediately. Since the target source files are not in this change and the referenced functions do not exist in the tree, these breakpoints cannot even be confirmed to be meaningful today. This reinforces that the file does not belong in version control. (high confidence)

Comment on lines +19 to +20

ghost Jul 27, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These breakpoints reference HOT-indexed logic (heapam.c HOT-indexed decision, the heap_hot_indexed_* helpers, heapam_indexscan.c, pruneheap.c redirect-with-data) that is not present in this changeset. I searched the tree and the heap_hot_indexed_* helpers do not exist. Combined with the fact that the files actually modified here are buffer-manager/regress/pgindent files, the debug config is inconsistent with the change's real scope: it points at code that isn't in the diff. (high confidence)

ghost Jul 27, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hardcoded line-number breakpoints are fragile: they drift the moment any line above them is edited, so gdb will silently stop at the wrong location without warning. The file already uses the maintainable form (function-name breakpoints like break heap_hot_search_buffer); prefer that everywhere, or break file:function where a specific function is meant. If a mid-function stop is truly needed, anchor it to a nearby unique symbol/label rather than an absolute line number.

ghost Jul 28, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hardcoded source line-number breakpoints (heapam.c:3210/4019/4024/4033/4101/4147, heapam_indexscan.c:182/250/297, indexam.c:299, execIndexing.c:370, pruneheap.c:1802/1836/1863/1287/2936) are extremely brittle: they become wrong the moment any line above them is added or removed, and the accompanying comments ('pure HOT', 'HEAP_INDEXED_UPDATED flag', 'redirect-with-data') are unverifiable against the tree since the corresponding feature code is not present. This reinforces that the file should be dropped rather than maintained.

ghost Sep 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The hardcoded source line breakpoints do not match the current tree and reference nonexistent code. Verified against the repo:

  • break heapam.c:3210 is a comment for simple_heap_delete, not heap_update (the file has 9524 lines; the comment here is wrong).
  • break heapam.c:4019/4024/4033 point to the deadlock-retry / no-TOAST branch of the existing update path, not any "pure HOT vs HOT indexed" decision.
  • break heapam_indexscan.c:250/297 and :182 reference HOT-indexed accumulator logic, but that file is only 299 lines and contains no such code.

Furthermore, the function-name breakpoints (heap_hot_indexed_create_tuple, heap_hot_indexed_serialize_bitmap, heap_hot_indexed_read_bitmap, heap_xlog_indexed_update, etc.) and the HEAP_INDEXED_UPDATED flag do not exist anywhere in the tree (code_search returned no matches). The entire "HOT indexed updates" series this file debugs is absent from both this review group and the other-changed-files list. This makes the file dead/misleading on its own commit and violates the atomic/bisectable-commit requirement: it documents and depends on code that was never added. [high confidence]

Comment on lines +19 to +20

ghost Oct 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire file does not belong in a commitfest-bound PR. Two independent, verifiable defects make it actively misleading:

  1. The hardcoded line-number breakpoints have already drifted. heapam.c:3210 is the closing brace of heap_delete() in the current tree, not heap_update() as this comment claims. Line-number breakpoints silently point at the wrong code the moment any surrounding line changes.

  2. Several function-name breakpoints below reference symbols that do not exist anywhere in the tree (heap_hot_indexed_create_tuple, heap_xlog_indexed_update, etc. -- see the comments on those lines). GDB will error on each unresolved breakpoint when the file is sourced.

Per the top-level .gitignore policy, local-workflow/editor scaffolding should be ignored via $GIT_DIR/info/exclude, not committed. Please drop this file from the patch.

Comment on lines +19 to +20

ghost Oct 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[high confidence] This developer-only debugging file must not be in a commitfest patch (see the local-workflow policy in .gitignore). Worse, it hardcodes line-number breakpoints such as heapam.c:3210, heapam.c:4019, and pruneheap.c:1802 that are tied to the exact feature diff. These silently rot the moment any of that code shifts by a line, so even as a dev aid they are a maintenance trap. Remove this file from the patch and keep it in a private local location.

ghost Oct 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These hardcoded source-line breakpoints are stale/wrong and actively misleading. Verified against the current tree: heapam.c:3210 is the closing brace of heap_delete (not the heap_update entry); heapam.c:4019 is a PageGetHeapFreeSpace check; heapam.c:4024 is inside a comment; heapam.c:4033 is a break;. None match the annotated HOT-indexed logic, and all line-number breakpoints silently drift after any edit to these files. If this file is kept at all, use function-name breakpoints (as the rest of the file already does) instead of file:line.

Comment on lines +19 to +20

ghost Oct 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The hardcoded absolute source line numbers (heapam.c:3210, heapam.c:4019, heapam.c:4033, heapam.c:4101, pruneheap.c:1802, execIndexing.c:370, etc.) will silently drift and attach to the wrong lines as the source evolves. Line-number breakpoints are inherently unmaintainable in a shared repo; combined with the stale heap_hot_indexed_* symbol references, this file is misleading. (Low severity because it is tooling, not shipped code -- the primary issue is that the file should not be in the patch at all.)

ghost Oct 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole file targets a "HOT indexed updates" patch series (heapam.c / pruneheap.c / execIndexing.c / indexam.c / heapam_indexscan.c), but the actual change in this PR is a buffer-manager / clock-sweep replacement-policy change (bufmgr.c, freelist.c, localbuf.c, buf_internals.h, bufmgr.h). None of the files these breakpoints reference are modified here. Beyond the already-noted non-existent function breakpoints, the hardcoded file:line breakpoints (e.g. break heapam.c:3210, break heapam.c:4101, break pruneheap.c:1802) are brittle and unrelated to this patch. Personal debugging scaffolding like this should not be part of a patch submitted upstream -- it is unrelated churn and will be rejected on the minimal-diff grounds.

Comment on lines +19 to +20

ghost Oct 5, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These breakpoints target a "HOT indexed updates" patch series that is not present in this repository. Verified against the tree: the symbols heap_hot_indexed_*, HEAP_INDEXED_UPDATED, and heap_xlog_indexed_update do not exist (no matches), and the hardcoded line numbers do not match the referenced files. For example heapam_indexscan.c is only 588 lines, so heapam_indexscan.c:182 is lp = PageGetItemId(page, offnum);, :250 is a blank line, and :297 is a return in heapam_index_plain_tuple_getnext_slot() -- none of which match the comments ("initialize bitmap accumulator", "accumulate bitmap from INDEXED_UPDATED tuple", "stale entry detection"). As written, every symbol breakpoint fails to resolve and every line-number breakpoint lands on unrelated code, making this file misleading and non-functional for anyone debugging this tree.

Comment on lines +19 to +20

ghost Oct 7, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Breakpoints pinned to absolute source line numbers are brittle and have already drifted. heapam.c:3210 is the closing brace of heap_delete — heap_update actually begins at line 3269. The accompanying prose ("Line 4019: pure HOT", "Line 4024: HOT indexed path", etc.) will desync from the file on any edit, making this file actively misleading. Function-name breakpoints (as used elsewhere in this file) are the only maintainable form; the numeric ones should be dropped. [high confidence]

ghost Oct 11, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These breakpoints target a "HOT indexed updates" patch series that is not present in this tree. The referenced symbols heap_hot_indexed_create_tuple, heap_hot_indexed_tuple_size, heap_hot_indexed_serialize_bitmap, heap_xlog_indexed_update (and the rest of the heap_hot_indexed_* family) do not exist anywhere in the source, so these breakpoints are dead/misleading on commit. In addition, every file:line breakpoint (heapam.c:3210, pruneheap.c:2936, heapam_indexscan.c:182, etc.) is pinned to a hardcoded line number that drifts on any edit, making the file wrong almost immediately. This file is unrelated to the change in this update and should not be committed (see .clangd comment).


# HOT decision block: pure HOT vs HOT indexed vs non-HOT
# Line 4019: pure HOT (no indexed columns changed)
# Line 4024: HOT indexed path (non-catalog, some indexed columns changed)
# Line 4031: predict augmented tuple size
# Line 4033: size+space check before creating augmented tuple
break heapam.c:4019

ghost Jul 28, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hardcoded file:line breakpoints (heapam.c:3210/4019/4024/4033/4101/4147, heapam_indexscan.c:182/250/297, indexam.c:299, execIndexing.c:370, pruneheap.c:1802/1836/1863/1287/2936) are extremely brittle: they drift with any unrelated edit and are meaningless outside one exact commit. The accompanying comments assert specific semantics per line (e.g. "Line 4019: pure HOT"), which become misleading documentation as the source evolves. None of these files even exist in this tree for this feature, so these references cannot be validated. This reinforces that the file does not belong in the patch.

break heapam.c:4024
break heapam.c:4033
Comment on lines +27 to +29

ghost Jul 27, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All break <file>:<line> directives depend on hardcoded absolute line numbers (heapam.c:3210/4019/4024/4033/4101/4147, heapam_indexscan.c:182/250/297, indexam.c:299, execIndexing.c:370, pruneheap.c:1802/1836/1863/1287/2936). These go stale the instant any referenced file shifts by a line, making the file misleading even as a private debugging aid. Prefer function-name breakpoints (as done elsewhere in this file) over line numbers. This is moot if the file is dropped, which it should be. (high confidence)

Comment on lines +27 to +29

ghost Aug 3, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolute-line-number breakpoints are extremely fragile: they drift with any edit to the target file and will silently point at unrelated code. For example heapam_indexscan.c:297 sits at the very end of a 299-line file, and none of the referenced heapam.c line numbers (4019/4024/4033/4101/4147) can be trusted because the feature they describe is not present. Even discounting the fact that this file should not be committed, line-pinned breakpoints are the wrong form; only symbolic (function-name) breakpoints are robust.

Severity: high confidence.

Comment on lines +27 to +29

ghost Aug 20, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confirmed stale/invalid line-number breakpoints. Line-number breakpoints rot the instant a file changes, and these are already wrong against the current tree: heapam.c:4019 is a deadlock-avoidance comment (not "pure HOT"), heapam.c:4024 is else {, and heapam.c:4033 is the comment "No TOAST work needed, and it'll fit on same page" - none match the annotations here. This gives a false impression of correctness and is entirely inappropriate for a committed file.

Comment on lines +27 to +29

ghost Oct 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hardcoded line-number breakpoints are already wrong against this tree. For example, the comment claims heapam.c:4019 is the "pure HOT (no indexed columns changed)" decision, but line 4019 of heapam.c in this repo is the generic re-fit check if (newtupsize > pagefree || ...). Line-number breakpoints are inherently brittle -- any edit shifts them so they silently point at unrelated code. Prefer function-name breakpoints (as used elsewhere in this file) over file:line form.

Comment on lines +27 to +29

ghost Oct 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These GDB breakpoints target a "HOT indexed updates" patch that is NOT present in this tree. Verified: heap_hot_indexed_create_tuple, heap_hot_indexed_tuple_size, heap_hot_indexed_serialize_bitmap, and heap_xlog_indexed_update do not exist anywhere in the source, so these function breakpoints will fail to resolve. The hardcoded line-number breakpoints are also wrong against the current tree: heapam_indexscan.c:182 is a PageGetItemId() call (not "redirect-with-data bitmap accumulator"), heapam_indexscan.c:250 is skip = false; (not "accumulate bitmap from INDEXED_UPDATED tuple"), and heapam_indexscan.c:297 is inside an unrelated static callback (not "stale entry detection"). This file is local developer scaffolding tightly coupled to one working-tree state and must not be committed to a patch destined for pgsql-hackers. (high confidence)

Comment on lines +27 to +29

ghost Oct 5, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hardcoded absolute line-number breakpoints (heapam.c:4019, heapam.c:4024, heapam.c:4033, pruneheap.c:1802, indexam.c:299, execIndexing.c:370, etc.) are extremely fragile: they silently drift to the wrong statement the moment any of these files change, which is a footgun during review/debugging. If this file is kept at all, prefer function-name + offset breakpoints over raw line numbers so they survive edits.


# Set HEAP_INDEXED_UPDATED flag on new tuple before page insertion
break heapam.c:4101

# Restore HEAP_INDEXED_UPDATED on old tuple (only if it previously had it)
break heapam.c:4147

# =========================================================================
# 2. TUPLE CREATION — building the augmented tuple with embedded bitmap
# src/backend/access/heap/heapam.c
# =========================================================================

# Predict augmented tuple size (returns 0 if t_hoff would overflow)
break heap_hot_indexed_tuple_size

ghost Jul 28, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file targets a HOT-indexed-updates feature (heap_hot_indexed_* helpers, HEAP_INDEXED_UPDATED, heap_xlog_indexed_update, XLOG_HEAP2_INDEXED_UPDATE) that does not exist anywhere in the tree - these symbols appear only inside .gdbinit. The actual changes in this series are limited to buffer management, pg_buffercache, pg_regress, and CI tooling. This is orphaned scaffolding for code not present in the changeset (YAGNI); if the feature commit is genuinely intended, its absence makes the series non-bisectable. Either way, this debug file should not be committed.


# Create augmented tuple with embedded modified-column bitmap
break heap_hot_indexed_create_tuple
Comment on lines +45 to +46

ghost Jul 19, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These breakpoints reference symbols that do not exist anywhere in this change: heap_hot_indexed_create_tuple, heap_hot_indexed_serialize_bitmap, heap_hot_indexed_tuple_size, heap_hot_indexed_bitmap_raw_size, heap_hot_indexed_read_bitmap, heap_hot_indexed_bitmap_overlaps_raw, heap_hot_indexed_merge_bitmaps_raw, heap_hot_indexed_deserialize_bitmap, and heap_xlog_indexed_update (there is no XLOG_HEAP2_INDEXED_UPDATE WAL record either). A search of the tree returns matches only inside .gdbinit itself. When sourced, GDB will error on every unresolvable symbol, and the file documents a code structure (new helper functions, a new WAL record, a HEAP_INDEXED_UPDATED flag) that is absent from the actual diff. This indicates the debug file is stale/aspirational relative to the patch content.

ghost Jul 28, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These symbols do not exist anywhere in the tree. A codebase search for heap_hot_indexed_create_tuple, heap_hot_indexed_serialize_bitmap, heap_hot_indexed_read_bitmap, heap_hot_indexed_bitmap_raw_size, heap_hot_indexed_merge_bitmaps_raw, heap_xlog_indexed_update, and the HEAP_INDEXED_UPDATED / XLOG_HEAP2_INDEXED_UPDATE identifiers returns matches only inside this .gdbinit. The referenced core commits are absent from this change, so the file documents behavior that is not present in the branch (breaking the atomic/bisectable-commit rule). Confidence: high.

Comment on lines +43 to +46

ghost Aug 3, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These breakpoints target a "HOT Indexed Updates" feature that does not exist in this changeset. The symbols heap_hot_indexed_create_tuple, heap_hot_indexed_serialize_bitmap, heap_hot_indexed_read_bitmap, heap_xlog_indexed_update, and the HEAP_INDEXED_UPDATED flag have zero matches anywhere in the codebase (verified), and heapam.c contains no heap_hot_indexed* functions at all. Sourcing this file would fail to set most of these breakpoints. This means the debug helper was committed without its corresponding feature code — the change is neither self-contained nor bisectable.

Severity: high confidence.

Comment on lines +45 to +46

ghost Oct 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

heap_hot_indexed_create_tuple does not exist anywhere in the source tree (verified via search). The surrounding heap_hot_indexed_* breakpoints in this block are likewise unresolved symbols. Sourcing this .gdbinit will produce an error for each one. These names appear to come from an unmerged feature branch, so the file is non-functional as committed.

Comment on lines +42 to +46

ghost Oct 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This .gdbinit (and the whole review group: .clangd, flake.nix, shell.nix, pg-aliases.sh) is personal developer-environment scaffolding unrelated to the actual change under review, which is a buffer-manager cooling-state rework (bufmgr.c SyncOneBuffer/cool_if_hot, buf_internals.h BUF_COOLSTATE_*, freelist.c StrategyCoolClaims). For a patch destined for pgsql-hackers/commitfest these files violate the minimal-diff rule and will draw immediate rejection; they should not be committed.

Worse, the breakpoints here target a completely different, nonexistent feature: the heap_hot_indexed_* functions (heap_hot_indexed_tuple_size, heap_hot_indexed_create_tuple, heap_hot_indexed_serialize_bitmap, etc.) do not exist anywhere in src/backend/access/heap/*.c in this tree. GDB will reject these as unresolved symbols. This confirms the file is stale scaffolding copied from an unrelated "HOT indexed updates" patch series and bears no relation to the buffer-manager change actually being reviewed. Remove the file from the patch.

Comment on lines +45 to +46

ghost Oct 5, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This entire file is developer-local scaffolding and should not be committed to a patch destined for pgsql-hackers/commitfest. It is unrelated to the HOT-indexed-updates feature itself and violates the minimal-diff discipline. Beyond that, it is broken as committed: the function-name breakpoints reference symbols that do not exist in this tree. heap_hot_indexed_create_tuple, heap_hot_indexed_serialize_bitmap, heap_xlog_indexed_update, etc. return no matches in the source, so GDB will reject these break commands as unresolved. Keep this in a local, un-tracked file (e.g. via .gitignore) instead.


# Serialize Bitmapset into raw bytes in tuple header
break heap_hot_indexed_serialize_bitmap

# =========================================================================
# 3. BITMAP UTILITIES — raw bitmap operations for chain following
# src/backend/access/heap/heapam.c
# =========================================================================

# Compute raw bitmap byte size from natts
break heap_hot_indexed_bitmap_raw_size

# Check if tuple header has room for bitmap between null bitmap and data
break heap_hot_indexed_has_bitmap_space

# Read HOT indexed bitmap from tuple header (returns Bitmapset)
break heap_hot_indexed_read_bitmap

# Fast overlap check: does tuple's raw bitmap overlap with indexed_attrs?
break heap_hot_indexed_bitmap_overlaps_raw

# OR a tuple's raw bitmap into an accumulator buffer
break heap_hot_indexed_bitmap_or_raw

# Check if accumulated raw bitmap overlaps with indexed_attrs
break heap_hot_indexed_accum_overlaps

# Merge bitmaps from dead tuples into a target tuple on the page
break heap_hot_indexed_merge_bitmaps_raw

# Deserialize raw bytes back to Bitmapset
break heap_hot_indexed_deserialize_bitmap

# =========================================================================
# 4. INDEX SCAN — HOT chain following with stale-entry detection
# src/backend/access/heap/heapam_indexscan.c
# =========================================================================

# Main HOT chain search with indexed update awareness
break heap_hot_search_buffer

# Redirect-with-data: initialize bitmap accumulator from collapsed redirect
break heapam_indexscan.c:182

# Accumulate bitmap from INDEXED_UPDATED tuple in chain
break heapam_indexscan.c:250

# Stale entry detection: accumulated bitmap overlaps this index's attrs
break heapam_indexscan.c:297

# =========================================================================
# 5. INDEX SCAN SETUP — indexed_attrs bitmap computation
# src/backend/access/index/indexam.c
# =========================================================================

# Compute indexed_attrs for HOT indexed update chain following
break indexam.c:299

# =========================================================================
# 6. INDEX INSERTION — skip unchanged indexes for HOT indexed updates
# src/backend/executor/execIndexing.c
# =========================================================================

# Entry: insert/update index tuples
break ExecInsertIndexTuples

# Index skip decision: skip indexes whose attrs don't overlap modified set
break execIndexing.c:370

# =========================================================================
# 7. PRUNING — chain collapsing and redirect-with-data
# src/backend/access/heap/pruneheap.c
# =========================================================================

# Main prune function
break heap_page_prune_and_freeze

# Per-chain pruning entry
break heap_prune_chain

# Chain collapsing: collect bitmaps from dead INDEXED_UPDATED intermediates
break pruneheap.c:1802

# OR dead tuple bitmaps into combined bitmap
break pruneheap.c:1836

# Record redirect-with-data for execute phase
break pruneheap.c:1863

# Execute phase: apply redirect-with-data entries on the page
break pruneheap.c:1287

# =========================================================================
# 8. WAL REPLAY — recovery of HOT indexed updates
# src/backend/access/heap/heapam_xlog.c
# =========================================================================

# WAL replay for XLOG_HEAP2_INDEXED_UPDATE
break heap_xlog_indexed_update
Comment on lines +144 to +145

ghost Oct 4, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neither heap_xlog_indexed_update nor the WAL opcode XLOG_HEAP2_INDEXED_UPDATE exists in the tree (verified via search). This breakpoint will fail to resolve on load.


# =========================================================================
# 9. WAL LOGGING — writing HOT indexed update records
# src/backend/access/heap/heapam.c
# =========================================================================

# WAL logging for heap updates (handles indexed_update flag)
break log_heap_update

# Serialize redirect-with-data into WAL record (pruneheap.c)
break pruneheap.c:2936

ghost Aug 20, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This breakpoint targets an out-of-range line: pruneheap.c currently has only 2759 lines, so pruneheap.c:2936 cannot exist. This proves the hardcoded line references are stale and meaningless in the current tree.

18 changes: 18 additions & 0 deletions .github/workflows/fork-ocr-model-check.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
# Weekly check for a newer Claude Opus on Bedrock; opens/updates one issue here
# when OCR_BEDROCK_MODEL is behind. Notify-only (GITHUB_TOKEN cannot write
# Actions variables). Logic lives in gburd/ci-workflows.

name: OCR model self-check

on:
schedule:
- cron: '0 12 * * 1' # Mondays 12:00 UTC
workflow_dispatch:

jobs:
check:
uses: gburd/ci-workflows/.github/workflows/ocr-model-check.yml@v1
with:
aws_role_arn: ${{ vars.AWS_ROLE_ARN }}
aws_region: ${{ vars.AWS_REGION }}
bedrock_model: ${{ vars.OCR_BEDROCK_MODEL }}
43 changes: 43 additions & 0 deletions .github/workflows/fork-ocr-review.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
# AI PR review (Claude Opus on Bedrock). Logic and review rules live in
# gburd/ci-workflows so this fork's master carries a stub instead of ~1000
# lines that have to be rebased onto upstream forever.
#
# Needs repo variables AWS_ROLE_ARN, AWS_REGION, OCR_BEDROCK_MODEL. Auth is
# GitHub OIDC; no static AWS keys. See the ci-workflows README.

name: OCR AI Review

on:
pull_request:
# Note: no draft filter — drafts are reviewed too.
types: [opened, synchronize, reopened, ready_for_review]
issue_comment:
types: [created]
workflow_dispatch:
inputs:
pr_number:
description: 'PR number to review'
required: true
type: number

# One review per PR; cancel superseded runs to save Bedrock spend.
concurrency:
group: ocr-review-${{ github.event.pull_request.number || github.event.issue.number || github.event.inputs.pr_number }}
cancel-in-progress: true

jobs:
review:
# Comment events only when the comment is on a PR and starts with the
# trigger keyword; PR events and manual dispatch always.
if: |
github.event_name == 'pull_request' ||
github.event_name == 'workflow_dispatch' ||
(github.event_name == 'issue_comment' && github.event.issue.pull_request &&
(startsWith(github.event.comment.body, '/open-code-review') ||
startsWith(github.event.comment.body, '@open-code-review') ||
startsWith(github.event.comment.body, '/pg-history')))
uses: gburd/ci-workflows/.github/workflows/ocr-review.yml@v1
with:
aws_role_arn: ${{ vars.AWS_ROLE_ARN }}
aws_region: ${{ vars.AWS_REGION }}
bedrock_model: ${{ vars.OCR_BEDROCK_MODEL }}
48 changes: 48 additions & 0 deletions .github/workflows/fork-sync-upstream.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
# Keep this fork's master rebased on postgres/postgres master, carrying only
# the fork-owned CI stubs (.github/workflows/fork-*.yml). The workflows they
# call, and the OCR review rules, live in gburd/ci-workflows.
#
# Requires the SYNC_TOKEN secret: a PAT with repo+workflow scope. The default
# GITHUB_TOKEN is not allowed to push commits that touch .github/workflows/,
# and every commit we carry does.

name: Sync from upstream

on:
schedule:
- cron: '17 */3 * * *'
workflow_dispatch:

concurrency:
group: fork-sync-upstream

permissions:
contents: read

jobs:
sync:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
with:
fetch-depth: 0
token: ${{ secrets.SYNC_TOKEN }}

- name: Rebase master onto upstream
run: |
set -euo pipefail
git config user.name "github-actions[bot]"
git config user.email "github-actions[bot]@users.noreply.github.com"
git remote add upstream https://github.com/postgres/postgres.git
git fetch --no-tags upstream master

# Master carries fork CI only. Anything else means work landed here
# that belongs on a branch; force-rebasing it on a timer would be wrong.
if git diff --name-only upstream/master...HEAD |
grep -v '^\.github/workflows/fork-'; then
echo "::error::master carries non-CI changes (listed above); move them to a branch"
exit 1
fi

git rebase upstream/master
git push --force-with-lease
3 changes: 2 additions & 1 deletion contrib/pg_buffercache/Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,8 @@ EXTENSION = pg_buffercache
DATA = pg_buffercache--1.2.sql pg_buffercache--1.2--1.3.sql \
pg_buffercache--1.1--1.2.sql pg_buffercache--1.0--1.1.sql \
pg_buffercache--1.3--1.4.sql pg_buffercache--1.4--1.5.sql \
pg_buffercache--1.5--1.6.sql pg_buffercache--1.6--1.7.sql
pg_buffercache--1.5--1.6.sql pg_buffercache--1.6--1.7.sql \
pg_buffercache--1.7--1.8.sql
PGFILEDESC = "pg_buffercache - monitoring of shared buffer cache in real-time"

REGRESS = pg_buffercache pg_buffercache_numa
Expand Down
1 change: 1 addition & 0 deletions contrib/pg_buffercache/meson.build
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,7 @@ install_data(
'pg_buffercache--1.4--1.5.sql',
'pg_buffercache--1.5--1.6.sql',
'pg_buffercache--1.6--1.7.sql',
'pg_buffercache--1.7--1.8.sql',
'pg_buffercache.control',
kwargs: contrib_data_args,
)
Expand Down
40 changes: 40 additions & 0 deletions contrib/pg_buffercache/pg_buffercache--1.7--1.8.sql
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
-- complain if script is sourced in psql, rather than via CREATE EXTENSION

ghost Oct 11, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an upgrade script, so the leading comment should refer to ALTER EXTENSION ... UPDATE (as the \quit message below does and as 1.6--1.7 does), not CREATE EXTENSION.

Suggested change
-- complain if script is sourced in psql, rather than via CREATE EXTENSION
-- complain if script is sourced in psql, rather than via ALTER EXTENSION

\echo Use "ALTER EXTENSION pg_buffercache UPDATE TO '1.8'" to load this file. \quit

-- Register the new functions.
CREATE OR REPLACE FUNCTION pg_buffercache_partitions()

ghost Oct 11, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use plain CREATE FUNCTION, not CREATE OR REPLACE, in an extension upgrade script that introduces a brand-new function. OR REPLACE masks accidental name collisions and diverges from the established convention in this extension's upgrade scripts (e.g. 1.6--1.7 uses plain CREATE FUNCTION for all new functions).

Suggested change
CREATE OR REPLACE FUNCTION pg_buffercache_partitions()
CREATE FUNCTION pg_buffercache_partitions()

RETURNS SETOF RECORD
AS 'MODULE_PATHNAME', 'pg_buffercache_partitions'
LANGUAGE C PARALLEL SAFE;

-- Create a view for convenient access.
CREATE VIEW pg_buffercache_partitions AS

ghost Oct 11, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No documentation and no regression tests accompany these new SQL-callable objects. The view pg_buffercache_partitions and function pg_buffercache_set_partition are user-visible, but doc/src/sgml/pgbuffercache.sgml is not updated (it still has no mention of pg_buffercache_partitions / set_partition), and no sql/expected regression coverage exists for the 1.8 objects. Per PostgreSQL commit standards a user-visible feature without tests and docs is WIP, not commit-ready; the error paths of pg_buffercache_set_partition (out-of-range partition, mismatched weight count, NULL/out-of-range weight, debug_clocksweep_balance_recalc enabled) in particular should have test coverage.

SELECT P.* FROM pg_buffercache_partitions() AS P
(partition integer, -- partition index
Comment on lines +12 to +13

ghost Oct 11, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indentation uses tabs here, but the other pg_buffercache SQL scripts (e.g. 1.6--1.7) indent with 4 spaces. Keep the new file consistent with the existing files to avoid gratuitous whitespace divergence.

numa_node integer, -- NUMA node of the partitioon

ghost Oct 11, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment typo: "partitioon" should be "partition".

Suggested change
numa_node integer, -- NUMA node of the partitioon
numa_node integer, -- NUMA node of the partition

ghost Oct 11, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spelling: "partitioon" should be "partition".

Suggested change
numa_node integer, -- NUMA node of the partitioon
(numa_node integer, -- NUMA node of the partition

num_buffers integer, -- number of buffers in the partition
first_buffer integer, -- first buffer of partition
last_buffer integer, -- last buffer of partition

-- clocksweep counters
num_passes bigint, -- clocksweep passes
next_buffer integer, -- next victim buffer for clocksweep
total_allocs bigint, -- handled allocs (running total)
num_allocs bigint, -- handled allocs (current cycle)
total_req_allocs bigint, -- requested allocs (running total)
num_req_allocs bigint, -- handled allocs (current cycle)

ghost Oct 11, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment copy-paste error: num_req_allocs is "requested allocs (current cycle)", not "handled allocs (current cycle)" (which is num_allocs on line 23). Fix the comment to match the SQL view in pg_buffercache_pages.c, which exposes buffer_req_allocs here.

Suggested change
num_req_allocs bigint, -- handled allocs (current cycle)
num_req_allocs bigint, -- requested allocs (current cycle)

ghost Oct 11, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment is wrong/copy-pasted: num_req_allocs is the requested-allocs count for the current cycle, but the comment duplicates the num_allocs wording ("handled allocs (current cycle)"). Should read "requested allocs (current cycle)".

Suggested change
num_req_allocs bigint, -- handled allocs (current cycle)
num_req_allocs bigint, -- requested allocs (current cycle)

weights int[]); -- balancing weights

-- Register the function to set clock-sweep balance weights.
CREATE FUNCTION pg_buffercache_set_partition(IN partition int, IN weights int[])
RETURNS void
AS 'MODULE_PATHNAME', 'pg_buffercache_set_partition'
LANGUAGE C VOLATILE PARALLEL UNSAFE;

-- Don't want these to be available to public.
REVOKE ALL ON FUNCTION pg_buffercache_partitions() FROM PUBLIC;
REVOKE ALL ON pg_buffercache_partitions FROM PUBLIC;
REVOKE ALL ON FUNCTION pg_buffercache_set_partition(int, int[]) FROM PUBLIC;

ghost Oct 11, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pg_buffercache_set_partition is only REVOKEd from PUBLIC with no role grant, so by default it is superuser-only; that is appropriate for a function that mutates shared buffer-manager state. However, there is no regression test exercising this new SQL surface: neither pg_buffercache_partitions nor the set_partition error paths (non-1-D array, NULL element, out-of-range partition, weight out of 0..100) are covered, and there is no pgbuffercache.sgml documentation for the two new functions in this change. A user-visible SQL addition without tests and docs is incomplete.


GRANT EXECUTE ON FUNCTION pg_buffercache_partitions() TO pg_monitor;
GRANT SELECT ON pg_buffercache_partitions TO pg_monitor;
2 changes: 1 addition & 1 deletion contrib/pg_buffercache/pg_buffercache.control
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
# pg_buffercache extension
comment = 'examine the shared buffer cache'
default_version = '1.7'
default_version = '1.8'
module_pathname = '$libdir/pg_buffercache'
relocatable = true
Loading
Loading