[jira] [Created] (HIVE-23143) Transactions: PPD in Delete deltas is broken

2020-04-06 Thread Abhishek Somani (Jira)
Abhishek Somani created HIVE-23143: -- Summary: Transactions: PPD in Delete deltas is broken Key: HIVE-23143 URL: https://issues.apache.org/jira/browse/HIVE-23143 Project: Hive Issue Type

Re: What is Hive 1.3.0 version

2019-03-18 Thread Abhishek Somani
There is no official release for Hive 1.3.0 yet. As I understand it, the fix that you mention exists in the "branch-1" branch, but I don't know(and I don't think) if there are plans for a release from that branch. Others here can confirm. If you need the fix, you might need to pull it and compile

[jira] [Created] (HIVE-21448) Insert Overwrite of a full ACID table when the select returns no data is not creating an empty base dir.

2019-03-14 Thread Abhishek Somani (JIRA)
Abhishek Somani created HIVE-21448: -- Summary: Insert Overwrite of a full ACID table when the select returns no data is not creating an empty base dir. Key: HIVE-21448 URL: https://issues.apache.org/jira/browse

Re: Hive ACID files compacted directory rename on cloud blob stores.

2018-11-26 Thread Abhishek Somani
Thanks for your reply. To clarify, do you mean that the problem is solved already because Hive ACID looks at the '_orc_acid_version' in the directory before assuming a directory is ready to read? Or do you mean that it *could have *looked at the file before deciding to read it and that would

Re: Hive ACID files compacted directory rename on cloud blob stores.

2018-11-11 Thread Abhishek Somani
Oh but s3Guard will not solve the atomicity problem, right? Reference: https://docs.hortonworks.com/HDPDocuments/HDP3/HDP-3.0.1/bk_cloud-data-access/content/ch03s07s01.html *What S3Guard Cannot Do* *...* *Mimic the "directory rename is a single atomic transaction" behavior of a filesystem like

Hive ACID files compacted directory rename on cloud blob stores.

2018-11-09 Thread Abhishek Somani
Hi, I have a question on using Hive ACID on Hive 3.x against cloud blob stores, would be much obliged if someone could answer the same. As I understand it, the results of a compaction(major or minor) need to be atomically visible, so that when there are uncompacted and compacted directories

Review Request 55046: HIVE-15390: Orc reader unnecessarily reading stripe footers with hive.optimize.index.filter set to true

2016-12-26 Thread Abhishek Somani
://issues.apache.org/jira/browse/HIVE-15390 Diffs - ql/src/java/org/apache/hadoop/hive/ql/io/orc/OrcRawRecordMerger.java fb7a6b2 Diff: https://reviews.apache.org/r/55046/diff/ Testing --- Thanks, Abhishek Somani

[jira] [Created] (HIVE-15390) Orc reader unnecessarily reading stripe footers with hive.optimize.index.filter set to true

2016-12-08 Thread Abhishek Somani (JIRA)
Abhishek Somani created HIVE-15390: -- Summary: Orc reader unnecessarily reading stripe footers with hive.optimize.index.filter set to true Key: HIVE-15390 URL: https://issues.apache.org/jira/browse/HIVE-15390

Re: More than one table created at the same location

2016-08-30 Thread Abhishek Somani
For the 2nd table(after both inserts are over), isn't the return count expected to be 4? In that case, isn't the the bug that the count was returned wrong(maybe from the stats as mentioned) rather the fact that another table was allowed to be created at the same location? I might be very wrong,