gc: separate checkpoint references from wal consumers
Initially, gc_consumer object was used for pinning both checkpoint and WAL files, but commit 9c5d851d ("replication: remove old snapshot files not needed by replicas") changed that. Now whether a consumer pins WALs or checkpoints or both depends on gc_consumer_type. This was done so that replicas wouldn't prevent garbage collection of checkpoint files, which they don't need after initial join is complete. The way the feature was implemented is rather questionable though: - Since consumers of both types are stored in the same binary search tree, we have to iterate through the tree to find the leftmost checkpoint consumer, see gc_tree_first_checkpoint. This looks inefficient and ugly. - The notion of advancing a checkpoint consumer (gc_consumer_advance) is dubious: there's no point to move on to the next checkpoint after reading one - instead the consumer needs incremental changes, i.e. WALs. To eliminate those questionable aspects and make the code easier for understanding, let's separate WAL and checkpoint consumers. We do this by removing gc_consumer_type and making gc_consumer track WALs only. For pinning the files corresponding to a checkpoint a new object class is introduced, gc_checkpoint_ref. To pin a checkpoint, gc_ref_checkpoint needs to be called. It is passed the gc_checkpoint object to pin, the consumer name, and the gc_checkpoint_ref to store the ref in. To unpin a previously pinned checkpoint, gc_checkpoint_unref should be called. References are listed by box.info.gc() for each checkpoint under 'references' key.
Loading
Please register or sign in to comment