Conversation
Idea is to use short term mutexes to protect arrays and hashes, and long term read locks for fdb and table read access. There is a live read/write for each fdb object. As long as there is a pointer to fdb, a read lock is acquired for that fdb. Each remote table is protected by its own long term read lock (similar to a table lock). There are two intervals when both table locks and fdb live lock are acquired: 1) during query preparing, if remote table discovery is needed, when we retrieve and attach remote tables; these locks are released once setup is done; the sqlite_stat tables are also locked during this phase 2) during query execution; we get an fdb live lock and table locks for each remote table locked, and we release them when unlocking the remote table Updating a table requires an exclusive lock on that table; to avoid blocking for long duration when a remote table is schema changed, we use a mvcc scheme that COW new table objects and detects readers using trywrlock. Last reader of a stable table will free that object. Signed-off-by: Dorin Hogea <dhogea@bloomberg.net>
roborivers
left a comment
There was a problem hiding this comment.
Cbuild submission: Error ⚠.
Regression testing: Success ✓.
The first 10 failing tests are:
commit_lsn_map
consumer_non_atomic_default_consumer_generated
fdb_compat_rte_connect_generated
fdb_push_rte_connect_generated
fdb_push_redirect_generated
fdb_push
fdb_compat
simple_remsql_whitelist_generated
simple_remsql_rte_connect_generated
simple_remsql_fdbpushredirect_generated
roborivers
left a comment
There was a problem hiding this comment.
Cbuild submission: Error ⚠.
Regression testing: Success ✓.
The first 10 failing tests are:
silogdel [core dumped]
sc_truncate_multiddl_generated
consumer_non_atomic_default_consumer_generated
sc_transactional_rowlocks_generated
fdb_compat_rte_connect_generated
fdb_compat
fdb_push_rte_connect_generated
fdb_push_redirect_generated
fdb_push
reco-ddlk-sql
trying to get regressions run here