Fix replication errors with tables containing generated columns #290
Conversation
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
PostgreSQL generated columns (GENERATED ALWAYS AS ... STORED) were causing errors during Spock replication. The issue occurred because generated columns were being treated as regular columns during: - Initial table synchronization (COPY operations) - Logical replication protocol messages - Default value filling for missing attributes - Conflict resolution and tuple processing Generated columns should not be replicated since they are computed automatically on the target database based on their definition. Solution: Add checks for attgenerated flag alongside existing attisdropped checks throughout the codebase to skip generated columns in: - spock_sync.c: COPY attribute list construction - spock_apply_heap.c: Default value filling - spock_proto_native.c: Native protocol tuple serialization - spock_proto_json.c: JSON protocol handling - spock_conflict.c: Conflict tuple formatting - spock_jsonb_utils.c: JSONB conversion utilities - spock_functions.c: Replication set table info - spock_repset.c: Attribute name lookup Test Coverage: Added regression test in sync_table.sql that verifies: - Table with STORED generated column can be added to replication set - Initial table synchronization works correctly via sub_resync_table() - Generated column values are correctly computed on subscriber - Both initial sync and ongoing replication handle generated columns
mason-sharp
approved these changes
Dec 19, 2025
Member
mason-sharp
left a comment
mason-sharp
left a comment
There was a problem hiding this comment.
Approving.
I tried pulling it down and reran the tests, changing STORED to VIRTUAL against Postgres 18, those passed as well.
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.
XXX:
There was a doubt about whether we need to support the LR of stored generated columns as the upstream does. This commit just skips them because of a) simplicity, and b) different types of generated columns have been introduced recently, and supporting LR, we would need to support two different implementations.
PostgreSQL generated columns (GENERATED ALWAYS AS ... STORED) were causing errors during Spock replication. The issue occurred because generated columns were being treated as regular columns during:
Generated columns should not be replicated since they are computed automatically on the target database based on their definition.
Solution:
Add checks for attgenerated flag alongside existing attisdropped checks throughout the codebase to skip generated columns in:
Test Coverage:
Added regression test in sync_table.sql that verifies:
co-author: Claude.