Github user ChinmaySKulkarni commented on the issue:

    https://github.com/apache/phoenix/pull/295
  
    @JamesRTaylor In the current (master) implementation of 
upgradeSystemTables, we only create SYSMUTEX in case we catch a 
TableAlreadyExistsException 
[link](https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java#L2683)
 when creating SYSCAT. Why don't we create SYSMUTEX (but not acquire a lock) in 
case of a NewerTableAlreadyExistsException or in case SYSCAT is successfully 
created?
    
    I guess this is because before this JIRA: Since we only intended to use 
upgradeSystemTables to actually upgrade SYSTEM tables and not to create them 
for the first time, SYSMUTEX was already created at this point. Is my 
assumption correct?
    
    With this JIRA, we now also use upgradeSystemTables to create all SYSTEM 
tables for the first time, so we should explicitly always try to create 
SYSMUTEX too.
    
    How about we call createSysMutexTableIfNotExists before trying to create 
SYSCAT and then only acquire the upgrade mutex in case of a migration and/or 
upgrade? We won't need this lock before creation of other SYSTEM tables since 
competing clients will get TableAlreadyExistsException (consistent with current 
master implementation too).



---

Reply via email to