Choose a database cursor that survives restarts
Database polling works when the cursor has a stable order and its checkpoint moves only after accepted work is owned.
- Published
- Updated
- Reading time
- 7 min read
Tested environment Synthetic PostgreSQL rows with equal timestamps, late commits and process restarts.
Use a total order
A timestamp alone can repeat. Pair it with a stable unique key so every row has one position. Query after the complete pair and use the same order in every page.
Move the checkpoint after ownership
Persist the next checkpoint only after the selected rows are durably admitted. If the process stops before that point, reading the rows again is safer than losing them. The work identity should make that repeat recognizable.
Test late visibility
Transactions can commit after a polling query begins. Test the database isolation level and decide whether a small overlap window or a source change log is needed.