...
- In wal-sync-thread (the only reader of mmap WAL), under the lock that synchronizes preparing ReadSegment and rolling the WAL segment, to guarantee there are no changes in the underlying buffer.
- Offers a deep copy of flushing ReadSegments to the CdcWorker.
- CdcWorker checks remaining capacity and the buffer size
- If the size fits the capacity then store the offered buffer data into the Queue.
- Otherwise:
- remove from the queue tail segments to free space for the offered buffer
- store the head of the offered buffer as nextHead (WALPointer)
- It captures data from the Queue while nextHead is not reached.
- Switch to the archiveMode.
Body loop (cdc-worker-thread)
- bufferMode:
- polls the Queue, transforms ReadSegment data to Iterator<CdcEvent>, pushes them to CdcConsumer.
- Optimization: transform segment buffers to CdcEvents in background (to reduce the buffer usage). CdcConsumer should be async then?
- archiveMode:
- similar to CdcMain - await archived segments
- submits the read WALRecords to the CdcConsumer.
- for every segment/record checks a condition to switch to the bufferMode:
- check the loaded WALPointer after initialization
- OR while nextHead is not reached
- In both modes it persists CdcConsumerState. Policy for committing the progress: by WAL segment.
...