0.2.0 release feature list

[igchor]

• Timestamp-based persistency
  • Expose pmemstream_entry_timestamp(struct pmemstream_entry) #202
  • Expose timestamps in API (return from append/publish)
  • Extend futures to 2 stages: commited, persisted
  • Expose pmemstream_async_wait_*(timestamp)
  • Add extra tests:
    • async_append and reserve/async_publish with custom data mover #229
    • [RC tests] timestamp order with multiple threads and multiple regions tests #211
    • more than PMEMSTREAM_MAX_CONCURRENCY concurrent operations
    • multithreaded async_append/async_publish and wait_committed/wait_persisted
  • Forbid multiple concurrent appends to the same region (even from a single thread) for now. Later, we might add some kind of transparent transactions to allow this.
  • Implement and test recovery. One approach (on Initial version of timestamp-based persistency #183) stores max_valid_timestamp in each region on recovery. An alternative approach could be to have an additional run_id variable incremented on each restart. Each region would store the current run_id in its metadata on recovery. We would also have some log/map which would correlate each run_id with a maximum valid timestamp. tests: verify timestamp recovery #192
  • Handle exceeding MAX_CONCURRENCY on append
  • Document what data is visible to iterators (committed vs persistent)
• Implement RocksDB-like API for iterators
• pmemstream_region_usable_size()
• manapages
• use pmem2_async_memcpy instead of vdm_memcpy Consider use pmem2_memcpy_async in async_append #163

[igchor]

@karczex: please add issue for testing recovery during recovery #213

@KFilipek: please add design of test: "timestamp order with multiple threads and multiple regions (concurrent async appends [thread_data_mover] to multiple regions)" #211

[igchor]

#229, #211 and #163 are moved to >= 0.3.0