Skip to content

Don't crash-loop the apply worker on a schema-mismatched column - #619

Merged
mason-sharp merged 3 commits into
v5_STABLEfrom
fix/SUP-213-unknown-column-crash-loop
Sep 17, 2026
Merged

mason-sharp merged 3 commits into
v5_STABLEfrom
fix/SUP-213-unknown-column-crash-loop

Conversation

@rasifr

@rasifr rasifr commented Sep 16, 2026

Copy link
Copy Markdown
Member

Don't crash-loop the apply worker on a schema-mismatched column

spock_relation_open() raised a bare elog(ERROR) for a remote column
missing locally, before the per-row exception-handling subtransaction
is ever entered, so spock.exception_behaviour never applied and the
same error kept re-throwing on every replay, restarting the worker
forever.

tupdesc_get_att_by_name() now returns -1 for a missing column instead
of erroring, and spock_relation_open() handles that the same way it
already handles an unresolvable relation: raise on the first attempt,
but return NULL during replay so the caller discards and logs the
action through the normal exception path.

Add a scheduled TAP test that creates a genuine schema mismatch: the
provider table has a column that is absent from the subscriber. Replicating
a row from that table reproduces an error while spock_relation_open() builds
the remote-to-local attribute map, before row-level exception handling is
entered.

Without the fix, exception replay raises the same error, restarts the apply
worker at the unadvanced origin LSN, and prevents later transactions from
replicating. Verify that the offending transaction is logged and discarded,
the subscription remains healthy, repeated mismatches do not cause a retry
storm, and unrelated transactions continue to replicate.
spock_relation_open() raised a bare elog(ERROR) for a remote column
missing locally, before the per-row exception-handling subtransaction
is ever entered, so spock.exception_behaviour never applied and the
same error kept re-throwing on every replay, restarting the worker
forever.

tupdesc_get_att_by_name() now returns -1 for a missing column instead
of erroring, and spock_relation_open() handles that the same way it
already handles an unresolvable relation: raise on the first attempt,
but return NULL during replay so the caller discards and logs the
action through the normal exception path.
@coderabbitai

coderabbitai Bot commented Sep 16, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 59d9c202-fd98-410d-8359-526a9d8c9c47

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Comment @coderabbitai help to get the list of available commands.

@codacy-production

Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 duplication

Metric Results
Duplication 0

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

@rasifr rasifr changed the title Fix/sup 213 unknown column crash loop Don't crash-loop the apply worker on a schema-mismatched column Sep 16, 2026
spock_relation_open() stopped at the first column the local relation
lacks, so repairing a drifted schema meant fixing one column, hitting the
same error, and repeating. Collect them all and report once. The wording
for a single missing column is unchanged, so existing tests still match.

Also close with NoLock on that path, matching every other apply-path
close: the lock is held until the replication transaction ends rather
than being dropped on a table we are part way through.
@mason-sharp
mason-sharp merged commit c5f56ef into v5_STABLE Sep 17, 2026
7 checks passed
@mason-sharp
mason-sharp deleted the fix/SUP-213-unknown-column-crash-loop branch September 17, 2026 16:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants