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
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
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
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 have
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 H
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 prese
://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
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
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, so