Does anyone know off-hand which privileges are nee...
# troubleshooting
d
Does anyone know off-hand which privileges are needed for catalog discovery in postgres? I’ve created a database user for meltano to use:
Copy code
CREATE ROLE meltano_robot WITH LOGIN PASSWORD 'TODO';
CREATE ROLE meltano_app;
GRANT rds_replication TO meltano_app;
GRANT CONNECT ON DATABASE mydb TO meltano_app;
GRANT USAGE ON SCHEMA public TO meltano_app;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO meltano_app;
GRANT USAGE ON ALL SEQUENCES IN SCHEMA public TO meltano_app;
However, I’m getting
RuntimeError: 0 tables were discovered across the entire cluster
a
I think you’ve covered the USAGE and SELECT permissions, which are the main ones. To confirm, did you run/rerun the
GRANT SELECT ON ALL TABLES…
after the tables were created? On other platforms I’ve run into the issue of the “ALL TABLES” clause only applying to currently-existing tables and not those to be created in the future.
d
The user can query all of the tables no problem, it just seems that it can’t run this query that the tap uses to get table details: https://github.com/transferwise/pipelinewise-tap-postgres/blob/master/tap_postgres/discovery_utils.py#L68-L108
If I run that query as the rds admin use, a bunch of rows are returned, but as my created user I get zero rows back.
Wait nm, the user can’t query all the tables no problem
I must have connected to the wrong db or something when I was testing. The problem was I didn’t actually assign the user to the role with all of the privs, lol:
Copy code
GRANT meltano_app TO meltano_robot;
a
That’s great news, I think. 🙂 Does that mean it seems to be working now?
d
It is thanks!
I thought there would be some obscure privs involved, but nope, just the bog standard
a
Awesome - I’m glad it’s working now!
c
Has anyone ever tried ELTing the actual
information_schema
itself to keep track of source systsem schema changes?
a
I did something similar in a past role. Specifically, we created a simplified yaml version of the catalog.json file and then committed that simplified file to source control. Periodically, or when something looked off, we'd check the version history on that catalog derivative to see what changed when. We could have gone further and done automated daily check-ins, but the visibility that gave us was I guess "good enough" that we didn't end up prioritizing the daily commit and automated comparison. It did come in really handy in a least a few occasions - to be able to quantify how many new columns were being added/dropped in Salesforce, for instance, and as the first thing to check if something downstream broke.
c
mm interesting
it’d be a sweet trick in meltano to have the option of flattening and storing into the loader the metadata
c
@dean_morin you just saved me some more time figuring out why this was failing. Thanks for posting your issue.