Repository navigation
Fix gpstart -R restricted mode and ADD COLUMN attmissingval across segments - #2241
Open
lss602726449 wants to merge 2 commits into
Open
lss602726449 wants to merge 2 commits into
lss602726449 wants to merge 2 commits into
Conversation
Restricted-mode gpstart passes superuser_reserved_connections equal to max_connections. GPDB relaxed the postmaster sanity check to allow that (commit c7649f1), but the PG16 merge of upstream commit 6e2775e, which added reserved_connections, rewrote the condition back to ">=" while keeping the GPDB comment. As a result the coordinator refused to start in restricted mode with "superuser_reserved_connections (150) plus reserved_connections (0) must be less than max_connections (150)". Restore the ">" comparison so the sum may equal max_connections. Sums that exceed it are still rejected. See: Issue#472
ALTER TABLE ... ADD COLUMN ... DEFAULT now() stored a different attmissingval on the coordinator and on every segment, which made gpcheckcat's inconsistent_pg_attribute check fail and made existing heap rows read a different value on each segment. GPDB used to evaluate the missing value once on the QD, in StoreAttrDefault, and dispatch it to the QEs in the ColumnDef (hasCookedMissingVal/missingVal). Upstream commit edc3bcc, merged with REL_16_9, moved the evaluation into ATExecAddColumn and stopped passing add_column_mode to StoreAttrDefault, so the dispatched value was never filled in or used. Each QE evaluated the stable default with its own transaction start time instead. Restore the dispatch in the new location: the QD stores the evaluated value in the ColumnDef as a one-element array and the QEs use it rather than evaluating the default themselves. For a table without storage, such as a partitioned table, the value is first evaluated on a child in the copied child command, so copy it back to the command that is dispatched. Drop the leftover missingMode handling before AddRelationNewConstraints to match upstream. Rows written by a table rewrite (AO tables, or a heap table rewritten because of a volatile default) still get a per-segment now(); that behavior predates PG16 and is not addressed here. See: Issue#473
reshke
approved these changes
Nov 6, 2026
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.
Cherry-picks two fixes from hashdata-lightning onto
main.1. Fix
gpstart -Rfailing onsuperuser_reserved_connectionsRestricted-mode
gpstartpassessuperuser_reserved_connectionsequal tomax_connections. GPDB had relaxed the postmaster sanity check to allow that (commitc7649f182fda), but the PG16 merge of upstream commit6e2775e4d4e4(which addedreserved_connections) rewrote the condition back to>=while keeping the GPDB comment. The coordinator then refused to start in restricted mode with:Restores the
>comparison so the sum may equalmax_connections; sums that exceed it are still rejected.See: Issue#472
2. Fix
attmissingvaldiffering across segments forADD COLUMNALTER TABLE ... ADD COLUMN ... DEFAULT now()stored a differentattmissingvalon the coordinator and on each segment, failing gpcheckcat'sinconsistent_pg_attributecheck and making existing heap rows read a different value per segment.GPDB used to evaluate the missing value once on the QD (in
StoreAttrDefault) and dispatch it to the QEs via theColumnDef. Upstream commitedc3bccd0dc(merged with REL_16_9) moved evaluation intoATExecAddColumnand stopped passingadd_column_mode, so the dispatched value was never filled in or used — each QE evaluated the stable default with its own transaction start time.Restores the dispatch in the new location: the QD stores the evaluated value in the
ColumnDefand the QEs use it instead of re-evaluating. For storage-less tables (e.g. partitioned tables) the value is evaluated on a child and copied back to the dispatched command. Table-rewrite rows (AO, or heap rewritten by a volatile default) still get a per-segmentnow(); that predates PG16 and is out of scope here.See: Issue#473
🤖 Generated with Claude Code