You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hive.apache.org by "Philipp Schuegerl (JIRA)" <ji...@apache.org> on 2014/10/31 13:28:33 UTC

[jira] [Commented] (HIVE-8684) Metastore caching too aggresive for partition location change

    [ https://issues.apache.org/jira/browse/HIVE-8684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191743#comment-14191743 ] 

Philipp Schuegerl commented on HIVE-8684:
-----------------------------------------

Potentially related to the already fixed 2758 (could have missed that ALTER TABLE ... SET statement)

> Metastore caching too aggresive for partition location change
> -------------------------------------------------------------
>
>                 Key: HIVE-8684
>                 URL: https://issues.apache.org/jira/browse/HIVE-8684
>             Project: Hive
>          Issue Type: Bug
>          Components: Metastore
>    Affects Versions: 0.12.0
>            Reporter: Philipp Schuegerl
>
> In a setup in which multiple metastores talk to a single MySQL DB, a partition location gets cached by the metastore although caching is turned off ("datanucleus.cache.level2" is set to "false").
> Reproduction steps:
> * Create a table <table> and partition <partition> with location X
> * Connect to hive with metastore A
> * Call ALTER TABLE <table> PARTITION (<partition>) SET LOCATION Y ... DESC FORMATTED <table> PARTITION (<partition>) will show location Y 
> * Connect to hive with metastore B
> * DESC FORMATTED <table> PARTITION (<partition>) will still show location X
> A workaround for this problem is to DROP the partition and recreate it (which correctly propagates to all metastores). Only the SET statement is affected by the bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)