{{ message }}
Repository navigation
Initialize all BaseStatistics members and zero stats_union - #23202
Merged
Mytherin merged 1 commit intoJun 11, 2026
Merged
Conversation
Claude writes: The default constructor and `Construct()` left `has_null`, `has_no_null` and `stats_union` (including its padding bytes) indeterminate; copies made during statistics propagation in the optimizer can read those bytes before `CreateEmpty`/`CreateUnknown` overwrite them, which valgrind flags in `StringValueComparison`. The new values match `InitializeEmpty()`, so behaviour is unchanged.
Member
krlmlr
pushed a commit
to krlmlr/duckdb
that referenced
this pull request
Jun 21, 2026
Conflict-free merge of the clean commits between resolutions: - Replace ARTConflictType::TRANSACTION with fatal exception (duckdb#23193) - [Dev] Fix variant shredding analysis logic discrepancy with shredded writing (duckdb#23194) - Initialize all `BaseStatistics` members and zero `stats_union` (duckdb#23202) - Initialize `TransactionContext::invalidation_policy` and `auto_rollback` (duckdb#23203)
krlmlr
pushed a commit
to krlmlr/duckdb
that referenced
this pull request
Jun 21, 2026
…b#23202) I've seen Valgrind complaining when the move constructor touches fields which are not initialized by default constructors. I can't tell whether this problem is "harmless by design" or whether we should really initialize and rely on the compiler optimizing it out where it matters. Claude writes: The default constructor and `Construct()` left `has_null`, `has_no_null` and `stats_union` (including its padding bytes) indeterminate; copies made during statistics propagation in the optimizer can read those bytes before `CreateEmpty`/`CreateUnknown` overwrite them, which valgrind flags in `StringValueComparison`. The new values match `InitializeEmpty()`, so behaviour is unchanged.
krlmlr
pushed a commit
to krlmlr/duckdb
that referenced
this pull request
Jun 21, 2026
Conflict-free merge of the clean commits between resolutions: - Replace ARTConflictType::TRANSACTION with fatal exception (duckdb#23193) - [Dev] Fix variant shredding analysis logic discrepancy with shredded writing (duckdb#23194) - Initialize all `BaseStatistics` members and zero `stats_union` (duckdb#23202) - Initialize `TransactionContext::invalidation_policy` and `auto_rollback` (duckdb#23203)
krlmlr
pushed a commit
to krlmlr/duckdb
that referenced
this pull request
Jun 21, 2026
Brings these v1.5-variegata commits; they do not overlap with the main/v2.0 line, so they merge with no conflicts: - Replace ARTConflictType::TRANSACTION with fatal exception (duckdb#23193) - [Dev] Fix variant shredding analysis logic discrepancy with shredded writing (duckdb#23194) - Initialize all `BaseStatistics` members and zero `stats_union` (duckdb#23202) - Initialize `TransactionContext::invalidation_policy` and `auto_rollback` (duckdb#23203)
krlmlr
pushed a commit
to krlmlr/duckdb
that referenced
this pull request
Jun 21, 2026
Brings these v1.5-variegata commits; they do not overlap with the main/v2.0 line, so they merge with no conflicts: - Replace ARTConflictType::TRANSACTION with fatal exception (duckdb#23193) - [Dev] Fix variant shredding analysis logic discrepancy with shredded writing (duckdb#23194) - Initialize all `BaseStatistics` members and zero `stats_union` (duckdb#23202) - Initialize `TransactionContext::invalidation_policy` and `auto_rollback` (duckdb#23203)
kaka11chen
pushed a commit
to kaka11chen/astrovela_vane
that referenced
this pull request
Aug 14, 2026
…b/duckdb#23202) I've seen Valgrind complaining when the move constructor touches fields which are not initialized by default constructors. I can't tell whether this problem is "harmless by design" or whether we should really initialize and rely on the compiler optimizing it out where it matters. Claude writes: The default constructor and `Construct()` left `has_null`, `has_no_null` and `stats_union` (including its padding bytes) indeterminate; copies made during statistics propagation in the optimizer can read those bytes before `CreateEmpty`/`CreateUnknown` overwrite them, which valgrind flags in `StringValueComparison`. The new values match `InitializeEmpty()`, so behaviour is unchanged. Upstream-Commit: duckdb/duckdb@c18e711
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I've seen Valgrind complaining when the move constructor touches fields which are not initialized by default constructors. I can't tell whether this problem is "harmless by design" or whether we should really initialize and rely on the compiler optimizing it out where it matters.
Claude writes:
The default constructor and
Construct()lefthas_null,has_no_nullandstats_union(including its padding bytes) indeterminate; copies made during statistics propagation in the optimizer can read those bytes beforeCreateEmpty/CreateUnknownoverwrite them, which valgrind flags inStringValueComparison. The new values matchInitializeEmpty(), so behaviour is unchanged.