Open xzhangxian1008 opened 1 month ago
It seems that there is data race when concurrently creating table.
MiniOB doesn't support creating tables or indexes concurrent. You must control it manually. But I will appreciate that if you create a pull request to fix this and I can discuss with you about the solution.
MiniOB doesn't support creating tables or indexes concurrent. You must control it manually. But I will appreciate that if you create a pull request to fix this and I can discuss with you about the solution.
okk, can you give me some hints about the solution.
Because github doesn't support the text send by email in markdown format, I rewrite it in github.
There are two points:
Db
;Table
, such as records insertion, deletion.It's easy to resolve the first problem. We can just add a lock
in the Db
when we access the tables_
data member.
But it's a little difficult to resolve the second problem. There is one solution from other database system. We can use table lock
to handle the concurrency between table schema changing and table records modifying.
Usually, we use different locking mode for thus operations. Let's say we have four locking mode:
Below is the locking compatible table:
Lock Mode | exclusive | shared | intent exclusive | intent shared |
---|---|---|---|---|
exclusive | X | X | X | X |
shared | X | √ | X | √ |
intent exclusive | X | X | √ | √ |
intent shared | X | √ | √ | √ |
As you can see, when you just want to visit the records of the table, you should get the intent
lock. When you want to change the schema of the table, such as adding index, you should get the exclusive
lock.
It seems
shared
lock is need now.
Before we want to do some actions, we should get the specific mode of lock.
You can use some other solutions as the table locking is a little complex. But please share your idea with me before you submit the Pull Request.
If you can complete this feature, I'd like to propose you to be the miniob committer.
Thanks.
Because github doesn't support the text send by email in markdown format, I rewrite it in github.
There are two points:
- creating tables in one
Db
;- creating tables or indexes while modifying records in the
Table
, such as records insertion, deletion.It's easy to resolve the first problem. We can just add a
lock
in theDb
when we access thetables_
data member. But it's a little difficult to resolve the second problem. There is one solution from other database system. We can usetable lock
to handle the concurrency between table schema changing and table records modifying.Usually, we use different locking mode for thus operations. Let's say we have four locking mode:
- exclusive. Only one worker can access the table. We can change the table schema or even drop the table if we hold this mode of lock. They also can modify the records.
- shared. Many workers can hold this mode of table lock at the same time and they can reading schema information and records from the table.
- intent exclusive. Workers who hold this mode of table lock won't change the schema of the table and they just want to modify records of the table.
- intent shared. Workers who hold this mode of table lock won't change the schema of the table and they just want to read records of the table.
Below is the locking compatible table:
Lock Mode exclusive shared intent exclusive intent shared exclusive X X X X shared X √ X √ intent exclusive X X √ √ intent shared X √ √ √ As you can see, when you just want to visit the records of the table, you should get the
intent
lock. When you want to change the schema of the table, such as adding index, you should get theexclusive
lock.It seems
shared
lock is need now.Before we want to do some actions, we should get the specific mode of lock.
You can use some other solutions as the table locking is a little complex. But please share your idea with me before you submit the Pull Request.
If you can complete this feature, I'd like to propose you to be the miniob committer.
Thanks.
Are there any blogs or paper that introduce the implemention of the online index?
Sure, here it is innodb intention locks and some other pages: https://severalnines.com/blog/understanding-lock-granularity-mysql/
SQL server: https://sqlundercover.com/2019/07/25/intent-locks-in-sql-server/
PostgreSQL: https://habr.com/en/companies/postgrespro/articles/500714/
ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging
Sure, here it is innodb intention locks and some other pages: https://severalnines.com/blog/understanding-lock-granularity-mysql/
SQL server: https://sqlundercover.com/2019/07/25/intent-locks-in-sql-server/
PostgreSQL: https://habr.com/en/companies/postgrespro/articles/500714/
ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging
get it
This is a simple design doc, many things may not be considered or described. Hope for your suggestions, I will improve it. PTAL. @hnwyllmm
Sorry that I response your message so late. I have read your document and I list the comments below in Chinese.
If you want, you can copy the document to oceanbase yuque. Tell me if you don't have the permission.
Lock
的实现描述来看,这里的锁并发控制,已经可以细化到页面和记录了。使用页面和记录锁来做并发控制,并不适用于索引等表结构变更与记录/行数据修改的并发控制。如果有兴趣可以加我微信(hnwyllmm_126),我们可以在miniob开发群中大家一起讨论。
4. 用于索引等表结构变
好的 我会做相应修改
Describe the bug A clear and concise description of what the bug is.
Environment Environment Details sometimes important
Fast Reproduce Steps(Required) Steps to reproduce the behavior:
Expected behavior A clear and concise description of what you expected to happen.
no crash
Actual Behavior What is the result? picture is allowed
crash
Additional context Add any other context about the problem here.