During the creation of system.views (created the first time a view is created in a database) a pre-commit hook, registered here, can be interrupted mid execution by a write conflict error, thrown here, crucially at a point where _pendingCommitNamespaces and _pendingCommitUUIDs were already updated, leaving the RAM contents of the catalog in an inconsistent state. Subsequent retries would fail indefinitely due to this inconsistency.

The underlying problem lies on the fact that the hook is performing I/O. The hook is supposed to always succeed, and storage access cannot generally hold this assumption. The solution would be to avoid storage access during two-phase commit: since the collection is being created it must be empty, so we should just clear the in-memory representation of the views.

Only affects 7.0.