Fixing “access denied” means granting the right privileges, roles, or connection permissions to the user who is being blocked in PostgreSQL.
PostgreSQL returns an “access denied” (permission denied) error when the current role lacks privileges to connect to a database, read a table, or execute a function. The fix is always to grant the missing privilege or change the role’s search path.
Run SELECT * FROM pg_catalog.pg_default_acl;
or psql -E
to see the exact GRANT the server expected. The error message often ends with “for relation tablename,” giving you the object needing a GRANT.
Use GRANT [privilege_list] ON [object] TO [role];
. Replace privilege_list with SELECT
, INSERT
, UPDATE
, etc., and object with table, schema, or database.
Create a role with a password and grant it CONNECT
on the target database. Also edit pg_hba.conf
to allow the client’s host and authentication method (typically md5
or scram-sha-256
).
1- CREATE ROLE app_user LOGIN PASSWORD 'strongpwd';
2- GRANT CONNECT ON DATABASE ecommerce TO app_user;
3- Edit pg_hba.conf
: host ecommerce app_user 0.0.0.0/0 scram-sha-256
4- Reload pg_ctl reload
or SELECT pg_reload_conf();
Grant the exact privilege on the table or, better, on the entire schema so future tables inherit the rule.
GRANT SELECT, INSERT ON ALL TABLES IN SCHEMA public TO app_user;
Yes, assign the built-in role pg_read_all_data
or pg_write_all_data
then revoke it once debugging finishes.
Yes. Over-granting breaks the principle of least privilege. Limit permissions to only what the application needs and audit pg_roles
regularly.
Yes. Run it once per schema so every new table automatically grants the required privileges without manual GRANTs.
Check role inheritance. If the login role is not a member of the role that owns the privileges, add it with GRANT role_name TO login_role;
.