Eric Jensen

Since metabase recommends 1-2GB Xmx setting maxResultBuffer=500M in the JDBC string would be preferable to using setFetchSize and setMaxRows since limiting by row count doesn't ensure they'll fit in memory...

It still seems the best solution to this would be using maxResultBuffer instead of setFetchSize/setMaxRows from the postgres driver, but I was mistaken above: the preferQueryMode=simple workaround fixes this problem...

I don't know of any reason to run the initialization more than once but i use aws_access_key_id not credentials_provider and I'm unclear on how/if save_access_token/get_access_token interacts with it...maybe try removing...

it's brittle but you need to pass the api client into the initializer like this https://github.com/ericcj/amz_sp_api#getting-started

there was some work on supporting grantless operations here i'd love to get something merged for it https://github.com/ericcj/amz_sp_api/pull/18

also support collation in case index uses one

this shouldn't actually be the source of a concurrency problem: http://dba.stackexchange.com/questions/158706/is-a-postgresql-subquery-in-autocommit-mode-part-of-the-same-transaction-or-a-di?noredirect=1#comment304489_158706 http://stackoverflow.com/questions/11532550/atomic-update-select-in-postgres#comment69692209_11568880

we'll patch it as per above

This sounds very similar to problems we are having. We haven't seen the OOM reproduce since we increased to Xmx6g so you might consider that as a workaround, but pretty...

good point here's three stack dumps over >20m from sending kill -QUIT 1 to the metabase java proc inside my docker. this instance currently has 17 leaked "Queries in flight"...