Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vstreamer: remove table locks for snapshots #8962

Closed

Conversation

derekperkins
Copy link
Member

Per @sougou in #8909, the snapshot connection should already be sufficient without introducing extra lock contention.

Related Issue(s)

May fix #8909

Checklist

  • I would like this to make it into the v12 release

the snapshot connection should already be sufficient without introducing extra lock contention

Signed-off-by: Derek Perkins <[email protected]>
@sougou
Copy link
Contributor

sougou commented Oct 11, 2021

I do think we need the lock. It's because the gtid we compute after starting a transaction can still change, and does not represent the gtid as of when the transaction was started.

@shlomi-noach
Copy link
Contributor

Agreed, the lock is required for GTID. However, as of MySQL 8.0.17, the table mysql.gtid_executed is always in sync with actual gtid_executed (before that version it would only update periodically and could represent older GTID set). Which means as of 8.0.17 we can potentially remove the lock and instead query for the GTID via SELECT * FROM mysql.gtid_executed inside the consistent snapshot.

Then again, this work on paralellising vstreamer copy: #8934, yet again required the lock and cannot work without it.

So I'd say let's keep the lock for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

vttablet: apparent deadlock when running PlannedReparentShard
3 participants