fix: resolve cross-shard type OIDs on first use instead of failing the query - #1514
Draft
rlittlefield wants to merge 1 commit into
Draft
fix: resolve cross-shard type OIDs on first use instead of failing the query#1514rlittlefield wants to merge 1 commit into
rlittlefield wants to merge 1 commit into
Conversation
…ad OID mappings on type DDL
rlittlefield
force-pushed
the
type-ddl-oid-refresh
branch
from
September 9, 2026 23:51
3c4a5ed to
7ef0b1a
Compare
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.
First of two PRs closing gaps in
canonicalize_type_informationfor types whose OIDs differ across shards (e.g. shards created with pg_dump/restore). The follow-up handles OIDs embedded in binary array/composite values.Motivation: Postgrex (Elixir) keeps one type cache per pool, learned from whichever shard answers its bootstrap query. Any
CREATE TYPEthat happens after PgDog loaded its OID mappings (a migration, DDL on another PgDog instance, or DDL run directly against the database) produced a RowDescription with an unmapped OID and the client failed withoid(s) ... lack type information.Behavior:
CREATE/DROPof enums, composites, ranges, domains, base types and extensions now set the schema-changed flag, soreload_schema_on_ddlcovers type DDL too.Server::send/readare split into client-facing and internal variants: PgDog's own catalog queries must not go through the refresh path, both to avoid recursion and so a refresh can't trigger another refresh.Testing: unit tests cover the DDL parser, mapping construction (including types missing on shard 0), held-back RowDescriptions, the reload fallback, and the unknown-canonical-OID checks for Parse/Bind.
integration/rustgains a test incross_shard_oid_drift.rs: a type created after PgDog loaded its mappings (with DDL reloads disabled) is inserted with a typed parameter and read back from every shard without a single failure, and the RowDescription OID matches shard 0's. Ran locally against a two-shard setup;cargo fmtandcargo clippyare clean.