[
https://issues.apache.org/jira/browse/HIVE-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13636294#comment-13636294
]
Phabricator commented on HIVE-3509:
-----------------------------------
njain has commented on the revision "HIVE-3509 [jira] Exclusive locks are not
acquired when using dynamic partitions".
INLINE COMMENTS
ql/src/java/org/apache/hadoop/hive/ql/lockmgr/HiveLockObject.java:144 This is
a incompatible change, and may break many existing apps.
For eg: in FB we log the query along with inputs and outputs, and this will
leave the
burden on the client to change / to @ appropriately.
Although it is not ideal, but let us stick with the format:
db@table@partns. where partitions is of partitionCol1/partitionCol2
REVISION DETAIL
https://reviews.facebook.net/D10065
To: JIRA, MattMartin
Cc: njain
> Exclusive locks are not acquired when using dynamic partitions
> --------------------------------------------------------------
>
> Key: HIVE-3509
> URL: https://issues.apache.org/jira/browse/HIVE-3509
> Project: Hive
> Issue Type: Bug
> Components: Locking
> Affects Versions: 0.9.0
> Reporter: Matt Martin
> Assignee: Matt Martin
> Attachments: HIVE-3509.1.patch.txt, HIVE-3509.D10065.1.patch,
> HIVE-3509.D10065.2.patch, HIVE-3509.D10065.3.patch, HIVE-3509.D10065.4.patch
>
>
> If locking is enabled, the acquireReadWriteLocks() method in
> org.apache.hadoop.hive.ql.Driver iterates through all of the input and output
> entities of the query plan and attempts to acquire the appropriate locks. In
> general, it should acquire SHARED locks for all of the input entities and
> exclusive locks for all of the output entities (see the Hive wiki page on
> [locking|https://cwiki.apache.org/confluence/display/Hive/Locking] for more
> detailed information).
> When the query involves dynamic partitions, the situation is a little more
> subtle. As the Hive wiki notes (see previous link):
> {quote}
> in some cases, the list of objects may not be known - for eg. in case of
> dynamic partitions, the list of partitions being modified is not known at
> compile time - so, the list is generated conservatively. Since the number of
> partitions may not be known, an exclusive lock is taken on the table, or the
> prefix that is known.
> {quote}
> After [HIVE-1781|https://issues.apache.org/jira/browse/HIVE-1781], the
> observed behavior is no longer consistent with the behavior described above.
> [HIVE-1781|https://issues.apache.org/jira/browse/HIVE-1781] appears to have
> altered the logic so that SHARED locks are acquired instead of EXCLUSIVE
> locks whenever the query involves dynamic partitions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
