Framework for Unsafe ALTER TABLE support

[jrolli]

Need to implement two mechanisms to support unsafe ALTER TABLE in a non-blocking manner:

• Rollback mechanism for removing a staged DataTableVersion (likely lives inside TransactionManager::Rollback
• Predicate check mechanism. Current plan is two-stages in lifecycle: Installed (visible and evaluated by all transactions immediately before commit; sets a failed flag if appropriate but still commits) & Enforced (visible and evaluated by all transactions and forces an abort if failed).

Sequencing for unsafe ALTER TABLE:

1. Grab begin timestamp
2. Parse query
3. Check if query executes an unsafe ALTER TABLE
4. Grab all planned write locks in the CATALOG (ensures fast abort and ensures schema change does not change between now and 6, below)
5. Install predicate
6. Fetch new "begin" timestamp
7. Execute table scan to check visible tuples for safety compliance.
8. Check predicate validity, abort now if invalid
9. Grab commit latch
10. Double-check validity, release latch and abort if invalid
11. Set predicate to enforcing.
12. Release commit latch.

Sequence for other transaction

1. [Proceed as normal until immediately before grabbing commit latch]
2. Run all predicate checks storing whether they succeeded or failed.
3. Check whether any failed predicates are enforcing, if so abort.
4. Grab commit latch
5. For each failed predicate, recheck enforcing. If now enforcing, release latch and abort.
6. Grab commit timestamp.
7. For each failed predicate, set validity flag to false.
8. [Proceed as normal starting with logic immediately after grabbing commit timestamp]

Lifecycle management for predicates:

• Immediately unlink on abort, GC with txn.
• For committed: unlink predicate when timestamp older than oldest running transaction.
• Delete predicate once unlink timestamp is older than oldest running transaction.

[jrolli]

After diving through the code, the hash map we are currently using is unsafe under our use case (implementation). This means we will either need an internal hash map implementation or a heavier wait process for executing rollbacks (i.e. copy over the hash map minus the removed element and CAS over to the new table). We can punt the issue further down the road by only installing the new version after we've confirmed commit (but this doesn't solve the problem for compaction in the future).