Part of the PG19 support umbrella: #8597.
Stacking: this work stacks on top of #8619 (columnar custom-scan relinfo). #8619 in turn lands on pg19-support, on top of the build foundation #8601 and the merged columnar-index PR #8618. PR4's branch is based on #8619's head (pg19-columnar-relinfo) so the diff stays clean; it auto-retargets to pg19-support once #8619 merges.
Three additional client-backend crashes surface only when running make check against PG19. They do not occur in everyday use because the triggering shapes are uncommon, but they are deterministic and reproducible in the suite.
1. columnar_scan_analyze_next_tuple() signature change — already handled in #8601
PG19 removed the OldestXmin parameter from the scan_analyze_next_tuple TableAM callback. Under full -Werror this was already fixed in the build foundation #8601 (#if PG_VERSION_NUM >= PG_VERSION_19 arm in columnar_tableam.c, mirrored in the test fake_am.c). No-op here — confirmed and dropped.
2. get_relation_info_hook was removed in PG19 — restore index stripping
Citus uses this hook to strip indexes from partitioned-table plans. The build foundation #8601 disabled the hook on PG19 (#if PG_VERSION_NUM < PG_VERSION_19 in shared_library_init.c, marked TODO(PG19 Phase 2)) to keep the build clean, leaving the index-stripping behaviour absent on PG19. This issue restores it: add a PG19-only multi_build_simple_rel_hook (in distributed_planner.c, declared in distributed_planner.h) that pulls inhparent / relationObjectId from the RangeTblEntry and delegates to the existing multi_get_relation_info_hook body, registered via build_simple_rel_hook under a #if PG_VERSION_NUM >= PG_VERSION_19 arm.
3. Relation opened with NoLock trips the PG19 relation_open assertion
PG19 tightened relation_open(rel, NoLock) to assert the caller already holds at least AccessShareLock. The central chokepoint is BuildDistributionKeyFromColumnName() in src/backend/distributed/utils/distribution_column.c, which performs an existence check via try_relation_open(relationId, lockMode) and is reached with NoLock along regress paths (e.g. distribution_column_map.c, EnsureColocateWithTableIsValid). Upgrade that existence-check open from NoLock to AccessShareLock and release the same lock on close. No-op on PG17/PG18 and when the caller already holds a lock. Reference commit 9ce63deaa.
Note: the original pg19-regress commit 117eef17e also carried a 5-line ruleutils_19.c hunk for generate_function_name's fgc_flags out-parameter. That is absorbed by PR1b #8602 and dropped here.
Correction (2026-06-27): an earlier draft named create_distributed_table_concurrently.c for item 3. That file does not exist in the tree; the fix lives in the shared distribution_column.c chokepoint described above, which all distribution-key callers funnel through.
Validation
PG17.10 / PG18.4 / PG19beta1 build green under -Werror; PG17/PG18 regression-neutral. PG19 make check no longer crashes in the columnar ANALYZE path (item 1), the partitioned-index planner path (item 2), or the distribution-key existence-check path (item 3).
Plan detail: pg19-pr-plan/04-regress-crashes.md (PR4).
Status (2026-06-27)
Part of the PG19 support umbrella: #8597.
Stacking: this work stacks on top of #8619 (columnar custom-scan relinfo). #8619 in turn lands on
pg19-support, on top of the build foundation #8601 and the merged columnar-index PR #8618. PR4's branch is based on #8619's head (pg19-columnar-relinfo) so the diff stays clean; it auto-retargets topg19-supportonce #8619 merges.Three additional client-backend crashes surface only when running
make checkagainst PG19. They do not occur in everyday use because the triggering shapes are uncommon, but they are deterministic and reproducible in the suite.1.
columnar_scan_analyze_next_tuple()signature change — already handled in #8601PG19 removed the
OldestXminparameter from thescan_analyze_next_tupleTableAM callback. Under full-Werrorthis was already fixed in the build foundation #8601 (#if PG_VERSION_NUM >= PG_VERSION_19arm incolumnar_tableam.c, mirrored in the testfake_am.c). No-op here — confirmed and dropped.2.
get_relation_info_hookwas removed in PG19 — restore index strippingCitus uses this hook to strip indexes from partitioned-table plans. The build foundation #8601 disabled the hook on PG19 (
#if PG_VERSION_NUM < PG_VERSION_19inshared_library_init.c, markedTODO(PG19 Phase 2)) to keep the build clean, leaving the index-stripping behaviour absent on PG19. This issue restores it: add a PG19-onlymulti_build_simple_rel_hook(indistributed_planner.c, declared indistributed_planner.h) that pullsinhparent/relationObjectIdfrom theRangeTblEntryand delegates to the existingmulti_get_relation_info_hookbody, registered viabuild_simple_rel_hookunder a#if PG_VERSION_NUM >= PG_VERSION_19arm.3. Relation opened with
NoLocktrips the PG19relation_openassertionPG19 tightened
relation_open(rel, NoLock)to assert the caller already holds at leastAccessShareLock. The central chokepoint isBuildDistributionKeyFromColumnName()insrc/backend/distributed/utils/distribution_column.c, which performs an existence check viatry_relation_open(relationId, lockMode)and is reached withNoLockalong regress paths (e.g.distribution_column_map.c,EnsureColocateWithTableIsValid). Upgrade that existence-check open fromNoLocktoAccessShareLockand release the same lock on close. No-op on PG17/PG18 and when the caller already holds a lock. Reference commit9ce63deaa.Validation
PG17.10 / PG18.4 / PG19beta1 build green under
-Werror; PG17/PG18 regression-neutral. PG19make checkno longer crashes in the columnar ANALYZE path (item 1), the partitioned-index planner path (item 2), or the distribution-key existence-check path (item 3).Plan detail:
pg19-pr-plan/04-regress-crashes.md(PR4).Status (2026-06-27)
pg19-supporttip.distributed_planner.c/distributed_planner.h/shared_library_init.c(item 2);distribution_column.c(item 3). Item 1 untouched; ruleutils hunk dropped.