I have a materialized view in Redshift that refreshes fine when I run refresh materialized view command, however the AWS Glue job is failing to refresh.
I'm not seeing any kind of error in the logs and reviewing the redshift query history shows it completing successfully. Additionally, the update time is the same so it does appear to be running correctly. However querying the view after glue updates does not show updated records, but does if I run the refresh.
I have ran the following permissions to grant the glue account access.
alter table reporting.my_view owner to glue;
alter schema reporting owner to glue;
grant all on schema reporting to glue;
grant all on all tables in schema reporting to glue;
alter default privileges in schema reporting grant all on tables to glue;
Try to use "commit;" before your main post actions query, for example:
"postactions": "commit; your_query"
REFRESH works for commited records only.
Related
How to create user that can create only tables in database?
grant create on database sport to test1; is wrong because we can create triggers too
There is no way to do that except with an event trigger that throws an error whenever the wrong user creates certain objects.
Note that creating tables or triggers is not connected to permissions on the database, but to permissions on the schema. It seems strange and arbitrary to me to prevent a user that can create tables from adding triggers to these tables.
I copied the tables from 1 Redshift Database to another Redshift Database through amazon redshift snapshots.
After successfully copying the tables from 1 DB to another DB there are some auto generated redshift tables "pg_automv.*" created.
I tried drop table pg_automv.auto_mv_******** command but it shows Error running query: permission denied for schema pg_automv result
Is there any way to delete or hide these tables from a specific users
I am executing sql file on linux by running script.
I can see my queries are getting executed fine but I have following query to refresh view in my testData.sql file that is giving me the error
refresh MATERIALIZED VIEW view_test
Error
psql:/home/test/sql/testData.sql:111: ERROR: must be owner of relation view_test
I have applied following permissions
grant select,update,delete,insert on view_test to "user123";
How to grant refresh permissions to the View in POSTGRESQL?
I would create a new role and set it as the new owner of the materialized view. Then add that role to any users you want able to refresh. This way an authenticated database user is not the owner, and you can add/remove users with permissions to it easily.
Error PostgreSQL requires us must be an owner for refreshing view_test. You can use alter table view_test owner to 'user123' command for changing the owner of this materialized view to user123
You should create a new role to own the view, then grant that role to any users who need permission to refresh the view. This ensures that you can easily assign the permission when you need to create additional user credentials.
CREATE ROLE refresh_materialized_views;
GRANT SELECT, INSERT, UPDATE, DELETE ON view_test TO refresh_materialized_views;
GRANT refresh_materialized_views TO user123;
GRANT refresh_materialized_views TO current_owner_of_view_test;
ALTER TABLE view_test OWNER TO refresh_materialized_views;
A tempting answer would be to alter the owner of the view to user123, but that's dangerous - you'd be breaking the current owner's access to their view.
created two schemas in redshift and one has all tables and other schema has views created from earlier schema tables. Users were granted select privileges on second schema views. When trying to query one particular view using select in redshift, it throws "Job::UserError: PG::InsufficientPrivilege: ERROR: permission denied for schema".
The error comes only when accessing that particular view, all others are absolutely fine.
Verified the privileges and users do have select permission on views and tables. Any direction would be helpful.
You must also grant the USAGE privilege on the new schema:
GRANT USAGE ON SCHEMA <schema_name> TO <schema_user>
If you find that this is only affecting one particular view, it may be because the view was dropped and recreated after the privileges were assigned (and therefore the table has lost its inheritance of the schema permissions).
The solution may be to:
Reapply the privileges
Next time you need to change the view, rather than DROP and then CREATE the view, use the CREATE OR REPLACE VIEW your_view_name AS command
I have a bit of a funny situation in Amazon Redshift where I have a user X who has grant select on all tables in schema public, but once a new table is created, this grant doesn't seem to apply to the new table. Is this normal behaviour? If yes, how does one deal with it such that the schema level grants are maintained. Thank you.
Executing the following command as super user (master):
alter default privileges
for user staging_user
in schema staging
grant select on tables
to reporting_user;
will allow reporting_user to select data from all future tables created by staging_user in schema staging.
In Redshift tables and views do not automatically inherit the permissions of their parent schema. Your newly created tables are only accessible to the user who created them, and the superuser.
In a recent patch to Redshift a new feature to grant default privileges was implemented that addresses this issue.
Alter Default Privileges
The following code snippet will grant select privileges only for all future tables in the sales schema to the sales_admin group. If you want this to apply to existing tables in a schema you will need to combine it with a second grant statement.
alter default privileges in schema sales grant select on tables to group sales_admin;
This is a normal behavior. Only the object owner/superuser have permission to use the object by default.
http://docs.aws.amazon.com/redshift/latest/dg/r_Privileges.html
You can add grant command to your create table statement and grant needed privileges for the user.
When we first spotted new tables not appearing in our reporting tool, I discovered a quick workaround is to re-execute the following SQL statement for the groups/users impacted:
ALTER DEFAULT PRIVILEGES IN SCHEMA <SCHEMANAME> GRANT SELECT ON TABLES TO GROUP <USER/GROUPNAME>;