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.

InlayHints:
Enabled: true
ParameterNames: true
DeducedTypes: true
CompileFlags:
CompilationDatabase: build/ # Search build/ directory for compile_commands.json
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.

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

#
# 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

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
#
# These breakpoints cover the major code paths introduced or modified by

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

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.

# 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
# src/backend/access/heap/heapam.c
# =========================================================================

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

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.

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

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

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.


# 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
break heapam.c:4024
break heapam.c:4033

# 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

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

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.


# 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

# =========================================================================
# 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
6 changes: 3 additions & 3 deletions contrib/pg_buffercache/pg_buffercache_pages.c
Original file line number Diff line number Diff line change
Expand Up @@ -161,7 +161,7 @@ pg_buffercache_pages(PG_FUNCTION_ARGS)
reldatabase = bufHdr->tag.dbOid;
forknum = BufTagGetForkNum(&bufHdr->tag);
blocknum = bufHdr->tag.blockNum;
usagecount = BUF_STATE_GET_USAGECOUNT(buf_state);
usagecount = BUF_STATE_GET_COOLSTATE(buf_state);

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 silently changes the user-visible semantics of the pg_buffercache.usagecount column. BUF_STATE_GET_USAGECOUNT returned the full clock-sweep count (0..BM_MAX_USAGE_COUNT, historically 0..5), whereas BUF_STATE_GET_COOLSTATE returns only bit 0 (0=COOL, 1=HOT). The column is still declared smallint and documented as "Clock-sweep access count", so users querying usagecount will now silently get only 0/1 with no doc or column-name update. This is a backward-incompatible behavior change that needs the documentation (pgbuffercache.sgml) updated and, arguably, the column renamed to reflect HOT/COOL semantics. (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.

This change alters the user-visible semantics of the usage_count column exposed by all three functions (pg_buffercache_pages, pg_buffercache_summary, pg_buffercache_usage_counts). BUF_STATE_GET_USAGECOUNT returned the full 0..N usage count, whereas BUF_STATE_GET_COOLSTATE returns only the 0/1 cooling state (bit 0 of the field). The documentation in doc/src/sgml/pgbuffercache.sgml still describes and shows a multi-valued "usage count" (e.g. the sample output table and the column descriptions "A possible buffer usage count"), and is not updated in this change. A user-visible SQL-interface change without matching docs is incomplete for a pgsql-hackers patch. Update pgbuffercache.sgml to reflect the new HOT/COOL cooling-state semantics (and consider whether the exposed column/variable naming should still be usage_count). (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.

This changes user-visible semantics: the pg_buffercache view's usage_count column now reports the 0/1 HOT/COOL cooling state instead of the historical 0..BM_MAX_USAGE_COUNT usage count (BM_MAX_USAGE_COUNT is now BUF_COOLSTATE_HOT == 1). doc/src/sgml/pgbuffercache.sgml still documents usage_count as "A possible buffer usage count" with old sample output and is not part of this change. A user-visible behavior change must ship with the doc update in the same patch. (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.

This silently changes the SQL-visible semantics of pg_buffercache. BUF_STATE_GET_COOLSTATE returns only 0 or 1 (bit 0 of the field: COOL/HOT), whereas the replaced BUF_STATE_GET_USAGECOUNT returned the full 0..N usage count. So the exposed usagecount column now only ever reports 0 or 1. This is a user-visible behavior change (POLA/backward-compat): the doc doc/src/sgml/pgbuffercache.sgml still calls this the "Clock-sweep access count" and is not updated in this change, so it now misdescribes the value. Either surface the underlying HOT/COOL state under a clearer name/description and update the docs, or keep reporting the raw usagecount field. 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.

This silently repurposes the user-visible usage_count column: it previously exposed the 0..BM_MAX_USAGE_COUNT usage counter but now returns only the 1-bit cooling state (0=COOL, 1=HOT). The SQL column name/type are unchanged, so existing queries and dashboards keep working but will now only ever see 0 or 1 -- a POLA/backward-compatibility surprise. This patch must be accompanied by an update to the pg_buffercache documentation (and expected regression output) describing the new semantics; consider whether the column should be renamed or the state exposed as text (HOT/COOL) instead of silently overloading usage_count. Confidence: high.

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 user-visible SQL behavior change that is not documented in this patch. The usagecount column of the pg_buffercache view is defined and documented as a 0..5 clock-sweep usage count. After this change it silently reports only 0 or 1 (the new HOT/COOL cooling bit), because BM_MAX_USAGE_COUNT is now BUF_COOLSTATE_HOT (1). The column name and its documentation (doc/src/sgml/pgbuffercache.sgml) still describe the old 0..5 semantics, so existing user queries/dashboards that interpret usagecount as a 0..5 popularity score will now be wrong with no warning. This must be accompanied by a doc update, and per PostgreSQL convention a change to the meaning of an existing extension-exposed column warrants a new pg_buffercache extension version rather than an in-place semantic redefinition. (moderate confidence)

pinning_backends = BUF_STATE_GET_REFCOUNT(buf_state);

if (buf_state & BM_DIRTY)
Expand Down Expand Up @@ -605,7 +605,7 @@ pg_buffercache_summary(PG_FUNCTION_ARGS)
if (buf_state & BM_VALID)
{
buffers_used++;
usagecount_total += BUF_STATE_GET_USAGECOUNT(buf_state);
usagecount_total += BUF_STATE_GET_COOLSTATE(buf_state);

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

usagecount_total now accumulates only 0/1 per buffer instead of 0..BM_MAX_USAGE_COUNT, so the derived usagecount_avg column changes range/meaning without any doc update. The SGML still labels it a clock-sweep average. Update the documentation to match the new HOT/COOL semantics. (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.

usagecount_avg (usagecount_total / buffers_used) now averages a 0/1 HOT/COOL bit instead of the historic 0..BM_MAX_USAGE_COUNT usage count, so the reported average collapses to [0,1]. This is a user-visible change to pg_buffercache_summary()'s output and its documented meaning; update the docs (pgbuffercache.sgml) and consider whether the column name still communicates the value. 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.

Same user-visible contract break here: usagecount_avg in pg_buffercache_summary() was the average of a 0..5 usage count; it now averages a 0/1 cooling bit, so its value range and meaning change silently. The summary function's documentation is not updated in this patch to reflect that the field is now effectively the fraction of HOT buffers. Update the docs (and consider whether the column should be renamed / versioned) so callers are not misled. (moderate confidence)


if (buf_state & BM_DIRTY)
buffers_dirty++;
Expand Down Expand Up @@ -655,7 +655,7 @@ pg_buffercache_usage_counts(PG_FUNCTION_ARGS)

CHECK_FOR_INTERRUPTS();

usage_count = BUF_STATE_GET_USAGECOUNT(buf_state);
usage_count = BUF_STATE_GET_COOLSTATE(buf_state);

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_usage_counts() now buckets buffers only into indices 0 and 1 (COOL/HOT); the usage_count output column will never exceed 1. This is fine for array bounds since BM_MAX_USAGE_COUNT is redefined to BUF_COOLSTATE_HOT (=1), but the SQL column name usage_count and its doc ("A possible buffer usage count") are now misleading. Update pgbuffercache.sgml and the expected regression output to reflect the reduced value domain. (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.

The local usage_count variable (and the usage_counts/dirty/pinned arrays it indexes) now holds a HOT/COOL cooling state (0 or 1), not a usage count. The name is now misleading and drifts from what the code does. Consider renaming to reflect the cooling state to avoid confusing future readers; the SQL column name may need to stay for compatibility, but the internal variable does not. (moderate 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.

pg_buffercache_usage_counts() is documented to aggregate buffers "over the possible usage count values" (0..5). With this change it can only ever emit two rows (usage_count 0 and 1), which is a user-visible change in the result set and its meaning. The array sizing is safe (BM_MAX_USAGE_COUNT is now 1 and BUF_STATE_GET_COOLSTATE returns only 0/1, so usage_counts[usage_count] stays in bounds), but the SQL/doc contract for this function needs updating to describe the new HOT/COOL semantics. (moderate confidence)

usage_counts[usage_count]++;

if (buf_state & BM_DIRTY)
Expand Down
78 changes: 78 additions & 0 deletions flake.lock

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

45 changes: 45 additions & 0 deletions flake.nix
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
{
description = "PostgreSQL development environment";

inputs = {
nixpkgs.url = "github:NixOS/nixpkgs/nixos-25.05";
nixpkgs-unstable.url = "github:nixos/nixpkgs/nixpkgs-unstable";
flake-utils.url = "github:numtide/flake-utils";
};

outputs = {
self,
nixpkgs,
nixpkgs-unstable,
flake-utils,
}:
flake-utils.lib.eachDefaultSystem (
system: let
pkgs = import nixpkgs {
inherit system;
config.allowUnfree = true;
};
pkgs-unstable = import nixpkgs-unstable {
inherit system;
config.allowUnfree = true;
};

shellConfig = import ./shell.nix {inherit pkgs pkgs-unstable system;};
in {
formatter = pkgs.alejandra;
devShells = {
default = shellConfig.devShell;
gcc = shellConfig.devShell;
clang = shellConfig.clangDevShell;
gcc-musl = shellConfig.muslDevShell;
clang-musl = shellConfig.clangMuslDevShell;
};

packages = {
inherit (shellConfig) gdbConfig flameGraphScript pgbenchScript;
};

environment.localBinInPath = true;
}
);
}
24 changes: 24 additions & 0 deletions glibc-no-fortify-warning.patch
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
From 130c231020f97e5eb878cc9fdb2bd9b186a5aa04 Mon Sep 17 00:00:00 2001
From: Greg Burd <greg@burd.me>
Date: Fri, 24 Oct 2025 11:58:24 -0400
Subject: [PATCH] no warnings with -O0 and fortify source please

---
include/features.h | 1 -
1 file changed, 1 deletion(-)

diff --git a/include/features.h b/include/features.h
index 673c4036..a02c8a3f 100644
--- a/include/features.h
+++ b/include/features.h
@@ -432,7 +432,6 @@

#if defined _FORTIFY_SOURCE && _FORTIFY_SOURCE > 0
# if !defined __OPTIMIZE__ || __OPTIMIZE__ <= 0
-# warning _FORTIFY_SOURCE requires compiling with optimization (-O)
# elif !__GNUC_PREREQ (4, 1)
# warning _FORTIFY_SOURCE requires GCC 4.1 or later
# elif _FORTIFY_SOURCE > 2 && (__glibc_clang_prereq (9, 0) \
--
2.50.1

Loading