prune_timestamp is the timestamp to indicate when we can garbage collect data from the ingest table. This value is updated when we adopt a new checkpoint and there is no active cursor on the btree.

However, if there is an active btree, prune_timestamp is not updated. This creates a delay for when data can be deleted. In the worst case, this may create a scenario that we always have an active cursor before we adopt a new checkpoint and thus prune_timestamp can never be updated. ddanderson Correct me if I'm wrong.

We need to figure out how to handle this case. You can reproduce this by removing the following line in test_layered38:

line 226: self.disagg_advance_checkpoint(conn_follow)