History-free databases don't keep transaction metadata #112
Labels
Comments
|
Probably not. This came as a surprise to some, though, so we should find a place to document this limitation explicitly. |
jamadden
added a commit
that referenced
this issue
Jul 2, 2019
Use row-level locking for objects being updated/conflicting; this doesn't use a timeout, but deadlocks are quickly detected by the RDBMS. Conflict resolution occurs before the TID is allocated and proceeds in parallel to the extent that objects are unrelated. We can't 100% safely defer the TID if we have a shared blob dir. Nor can we currently defer it if use undo(). There's still a database-wide lock taken to allocate the final TID. This can easily go away for history-preserving databases, a little less easily for history free (one idea is to track transactions; see #112). It probably does need to go away and switch entirely to row-level locks, as the integration of advisory locks with row locks can be confusing and hard to debug --- RDBMS deadlock detection doesn't necessarily catch advisory locks. And we'd like to keep things as simple and straightforward as possible. There's some debugging cruft left to clean up in this, I want to see if it passes on CI first. PostgreSQL was a breeze to get working, MySQL was much more of a pain (5.7 won't report on locks that are pending, only those already in conflict! Fortunately 8 is much better, But still, it seems that doing one query with 'FOR UPDATE' and in the same transaction on the same rows doing one with 'LOCK IN SHARE MODE' does Very Bad things, such as releasing the original update lock or something, such that we could deadlock).
This was referenced Jul 2, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
They don't have a transaction table to record this metadata anywhere, so consequently it can't be stored or retrieved.
Can we come up with an efficient (cheap) way to store this data for live transactions (those that still have objects) in history-free databases?
The text was updated successfully, but these errors were encountered: