[
https://issues.apache.org/jira/browse/PHOENIX-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16434935#comment-16434935
]
ASF GitHub Bot commented on PHOENIX-4579:
-----------------------------------------
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).
> Add a config to conditionally create Phoenix meta tables on first client
> connection
> -----------------------------------------------------------------------------------
>
> Key: PHOENIX-4579
> URL: https://issues.apache.org/jira/browse/PHOENIX-4579
> Project: Phoenix
> Issue Type: New Feature
> Reporter: Mujtaba Chohan
> Assignee: Chinmay Kulkarni
> Priority: Major
> Attachments: PHOENIX-4579.patch
>
>
> Currently we create/modify Phoenix meta tables on first client connection.
> Adding a property to make it configurable (with default true as it is
> currently implemented).
> With this property set to false, it will avoid lockstep upgrade requirement
> for all clients when changing meta properties using PHOENIX-4575 as this
> property can be flipped back on once all the clients are upgraded.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
