Repository navigation
fix: rescope pg_graphql and pg_cron event triggers during pg_upgrade - #2478
Merged
utkarash2991 merged 5 commits intoSep 25, 2026
Merged
Conversation
Old projects still have these event triggers scoped to CREATE FUNCTION / CREATE SCHEMA while the fleet-updated grant functions only act on CREATE EXTENSION events, so the post-upgrade extension recreation never re-applies their wiring. Rescope in initiate.sh before the extensions are dropped (the fixed triggers travel through pg_upgrade) and again in complete.sh before the generated SQL runs, as a safety net.
mmlb
requested changes
Sep 21, 2026
imor
reviewed
Sep 22, 2026
Both instances download the same target-version script bundle, so the older-bundle scenario the complete.sh safety net guarded against doesn't occur in practice. Keep the single rescope in initiate.sh and wrap it in retry, since it is fail-soft and a skipped rescope silently loses the extension wiring.
mmlb
requested changes
Sep 22, 2026
imor
reviewed
Sep 25, 2026
imor
approved these changes
Sep 25, 2026
utkarash2991
deleted the
utkarashsingh/pg-graphql-trigger-rescope-upgrade
branch
September 25, 2026 19:11
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
3 participants
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.
Old projects still have
issue_pg_graphql_accessscoped toCREATE FUNCTION(created before 17.6.1.111 / 15.14.1.111) andissue_pg_cron_accessscoped toCREATE SCHEMA(created before 15.1.0.130), while the grant functions they invoke were since updated fleet-wide and only act onCREATE EXTENSIONevents. With that mismatch, recreating the extensions during an upgrade never re-applies their wiring:graphql_public.graphqlis left as the "not enabled" placeholder and the postgres role's cron grants are skipped.How the mismatch crept in:
issue_pg_cron_accessonCREATE SCHEMA(2022); the pg_graphql trigger was likewise seeded onCREATE FUNCTION20260421000001(first shipped in 17.6.1.111 / 15.14.1.111) rescoped trigger + function together — but migrations only run at image build, so existing projects kept the old triggersCREATE EXTENSION-scoped bodies, leaving old projects with a trigger that fires on events the new functions ignorecomplete.sh, which (like the pg_graphql disable/re-enable that was always part of pg_upgrade) now silently loses the wiring on those projectsThis adds a
rescope_extension_event_triggershelper tocommon.shand calls it from two places:initiate.sh, before the extensions are dropped — the rescoped triggers are carried into the new cluster by pg_upgrade, and the failure-path re-enable on the source instance is covered as wellcomplete.sh, beforerun_generated_sqlrecreates the extensions — safety net in case the source ran an older script bundleLinear: PSQLEXT-1672