Details
-
Type:
Task
-
Status: Stalled (View Workflow)
-
Priority:
Critical
-
Resolution: Unresolved
-
Fix Version/s: 10.11
-
Component/s: Storage Engine - Spider
-
Labels:None
Description
Implement a connection management mechanism to Spider to make the connection handing easy.
- Each thread gets/returns connections from/to the connection manager. Allocation and deallocation of connections should be done inside the connection manager code.
- Each connection got from the manager should solely belong to a single thread. Note that, in the current implementation, a single connection is referenced by both ha_spider::conns and SPIDER_TRX::trx_conn_hash and this results in the heap-use-after-free (see linked issues) in many test cases.
- Spider 10.3-10.9 has two types of connections. One is for SQL and the other is for handler statements. The latter one has been deprecated from 10.7 and deleted by 10.10. So, we only implement the connection manager for SQL connections.
- For the ease of the development, I recommend creating a patch for 10.10 first and then backporting it to 10.3.
Attachments
Issue Links
- relates to
-
MDEV-27902 SIGSEGV's in spider_check_and_set_trx_isolation, spider_db_open_handler, and ha_spider::external_lock and __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed in psi_mutex_lock and inline_mysql_mutex_lock, and SIGABRT in safe_mutex_lock
-
- Stalled
-
-
MDEV-28352 Spider: heap-use-after-free in ha_spider::lock_tables(), heap freed by spider_commit()
-
- Closed
-
-
MDEV-28676 Spider: Got error 12701 when reading table, when using HANDLER
-
- Confirmed
-
-
MDEV-28683 Spider: SIGSEGV in spider_db_direct_delete and SIGSEGV in spider_db_connect
-
- Stalled
-