fix: use pg_lsn cast for LSN comparison in slot advance resource#391
Conversation
|
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 (2)
📝 WalkthroughWalkthroughThis PR replaces Go string-based LSN comparison with a PostgreSQL-native comparison. A new ChangesLSN Comparison and Replication Slot Advancement
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 docstrings
🧪 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
|
| Metric | Results |
|---|---|
| Duplication | 0 |
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.
Summary
This PR fixes an issue where
ReplicationSlotAdvanceFromCTSResourcecompared target and current LSNs using Go’s string<=operator, which can produce incorrect results across segment boundaries (for example,"F/FFFFFFFF"is lexicographically greater than"10/00000000"even though it is numerically smaller). This could silently skip replication slot advancement during add-node workflows. The fix delegates the comparison to PostgreSQL’s nativepg_lsntype for correct LSN ordering.Changes
Add
LsnAtOrBefore(lsn1, lsn2 string)query topostgres/create_db.gousing:SELECT @lsn1::pg_lsn <= @lsn2::pg_lsnReplace the Go string comparison (
targetLSN <= currentLSN) inReplicationSlotAdvanceFromCTSResource.Create()withLsnAtOrBefore()to ensure correct LSN ordering semantics.PLAT-627