Conversation
The migration functions shuffle rows between pg_catalog.pg_largeobject and the lolor tables. The native side is a system catalog that logical decoding never streams, so each node holds an independent set of native large objects and the migration can only ever be performed per node. The lolor side, however, consists of ordinary replicated tables, so the bulk migration DML used to leak to subscribers: migrate_from_native() fanned out rows that remote nodes must produce themselves, and migrate_to_native() replicated its deletes while the re-created native objects stayed local, destroying large objects on the subscriber side. When spock is installed, run both functions under spock.repair_mode() so the migration DML is excluded from logical decoding. Enter repair mode only when spock is fully operational (extension installed, function present, library preloaded) and leave it again right after the migration DML, so statements later in the caller's transaction replicate normally. The pg_extension check also prevents a planted 'spock' schema from being executed with superuser rights. Without spock the DML cannot be excluded from decoding, so refuse to migrate while logical replication slots exist in the database: migrate_from_native() warns and returns -1 (0 stays reserved for "nothing to migrate"), migrate_to_native() raises an error, which also makes DROP EXTENSION fail instead of silently dropping the lolor tables with the objects still inside. After a successful migration, emit a NOTICE reminding the operator to run the same migration on each replica before modifying large objects. Update README, docs and release notes accordingly: the previous "migrate on one node and let the rows replicate" model is replaced by the node-local model, orchestrated e.g. via spock.replicate_ddl().
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughThis PR adds logical replication awareness to large-object migration functions by detecting replication slots and conditionally using ChangesReplication-safe large-object migration with spock repair mode
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Up to standards ✅🟢 Issues
|
1 participant
The migration functions shuffle rows between pg_catalog.pg_largeobject and the lolor tables. The native side is a system catalog that logical decoding never streams, so each node holds an independent set of native large objects and the migration can only ever be performed per node. The lolor side, however, consists of ordinary replicated tables, so the bulk migration DML used to leak to subscribers: migrate_from_native() fanned out rows that remote nodes must produce themselves, and migrate_to_native() replicated its deletes while the re-created native objects stayed local, destroying large objects on the subscriber side.
When spock is installed, run both functions under spock.repair_mode() so the migration DML is excluded from logical decoding. Enter repair mode only when spock is fully operational (extension installed, function present, library preloaded) and leave it again right after the migration DML, so statements later in the caller's transaction replicate normally. The pg_extension check also prevents a planted 'spock' schema from being executed with superuser rights.
Without spock the DML cannot be excluded from decoding, so refuse to migrate while logical replication slots exist in the database: migrate_from_native() warns and returns -1 (0 stays reserved for "nothing to migrate"), migrate_to_native() raises an error, which also makes DROP EXTENSION fail instead of silently dropping the lolor tables with the objects still inside.
After a successful migration, emit a NOTICE reminding the operator to run the same migration on each replica before modifying large objects.
Update README, docs and release notes accordingly: the previous "migrate on one node and let the rows replicate" model is replaced by the node-local model, orchestrated e.g. via spock.replicate_ddl().