GC Txn entries through GC queue#3185
Conversation
storage/replica.go
Outdated
There was a problem hiding this comment.
Does this change imply that you've seen this error in practice now? In general we shouldn't both log and return an error; just pass them up the stack and log them we we can no longer return the error.
|
updated, PTAL Review status: 0 of 16 files reviewed at latest revision, 5 unresolved discussions. storage/gc_queue.go, line 54 [r1] (raw file): storage/gc_queue.go, line 68 [r1] (raw file): storage/gc_queue.go, line 322 [r1] (raw file): storage/gc_queue_test.go, line 390 [r1] (raw file): storage/replica.go, line 1586 [r1] (raw file): Comments from the review on Reviewable.io |
|
LGTM |
see cockroachdb#2062. on each run of the GC queue for a given range, the transaction and sequence prefixes are scanned and the following actions taken: * old pending transactions are pushed (which will succeed), effectively aborting them * old aborted transactions are added to the GC request. * aborted and committed transactions will have the intents referenced in their record resolved synchronously and are GCed (on success) * sequence cache entries which are "old" and belong to "old" (or nonexistent) transactions are deleted.
see #2062. This is a bit of a late Friday throw-over-the-wall but should generally be ready for review.
on each run of the GC queue for a given range, the transaction
and sequence prefixes are scanned and the following actions taken:
aborting them
in their record resolved synchronously and are GCed (on success)
nonexistent) transactions are deleted.
The implementation here isn't as performant as it could be by a long shot,
but very few txn/sequence cache entries should actually persist long enough
to be observed by this queue. Normally, transaction records are eagerly
removed after commit along with their sequence cache entries (much like
intents are usually resolved).
fixes #2062.