hive-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Furcy Pin <>
Subject Re: How can I identify permissions issues given problematic SQL?
Date Wed, 16 Aug 2017 08:59:26 GMT
Hi Giles,

Did you try running the query with the EXPLAIN AUTHORIZATION clause?

On Wed, Aug 16, 2017 at 3:08 AM, Bear Giles <> wrote:

> Hi, an issue came up during recent AT and I'm hoping someone will have
> ideas on how we can check for this in the future, esp. if we can automate
> it somehow.
> In this case we had a client using our Hive client in the existing release
> without problems. When they copied their process to the UAT system for the
> final User Acceptance Testing it failed and they reported it as a defect in
> our pending release.
> I looked at it - when I ran the query I got a generic SQL Exception
> message. (If there were further details we didn't capture them.) It
> consistently took about 20 minutes to get the error. I simplified the query
> repeatedly in order to reduce the number of unknowns but it was always a
> generic SQL Exception that took about 20 minutes... except for the one time
> it took 4 hours(!).
> However we had a valid connection. I could execute 'select 1 as x' and get
> an immediate response. (Maybe 20s, but "immediate" when you've been waiting
> 20 minutes or more.)  Clearly I didn't have bad credentials.
> I tried running DESCRIBE table and SHOW tables but didn't get anything
> useful due to a bug in our software - we're treating those as a statement
> instead of a query so I didn't get anything useful. I couldn't push a fix
> either since we were in UAT and the other machines weren't whitelisted to
> access their servers.
> I made an informed guess that it could be a permissions issue with the
> underlying tables and they should check that. Nothing else made sense - we
> were clearly establishing a connection and the only difference between
> production and UAT was the host running the software. The customer was
> skeptical but eventually double-checked the connection properties and
> permissions and determined that there was a difference between the systems.
> I don't know what the ultimate problem was. I'm pretty sure it wasn't just
> a different account that didn't have the table - IIRC I did a test where I
> tried to select records from a non-existent table and it returned quickly
> with a meaningful error.
> My questions:
> 1. What conditions could result in the ability to establish a connection,
> run a query such as 'select 1 as x', but take 20 minutes to throw an error
> when I run a query like 'select guid from foo limit 1'?
> 2. How can I test for them? Now that we're post-UAT (and this is a known
> concern) we can add logic to perform standard tests for missing permissions
> if we know what to do.
> Thanks.
> Bear Giles
> Sr. Java Application Engineer
> Mobile: 720-749-7876 <(720)%20749-7876>
> <>
> *SnapLogic Inc | 929 Pearl St #200 | 80303 CO 80302 | USA*
> *SnapLogic Inc | 2 W 5th Avenue 4th Floor | San Mateo CA 94402 | USA   *
> This message is confidential. It may also be privileged or otherwise
> protected by work product immunity or other legal rules. If you have
> received it by mistake, please let us know by e-mail reply and delete it
> from your system; you may not copy this message or disclose its contents to
> anyone. The integrity and security of this message cannot be guaranteed on
> the Internet.

View raw message