The following view created in an “admin” schema shows locks and more specifically blocking locks – in the column “blocking_pid”
create view admin.show_blocking_locks as
select a.txn_owner, a.txn_db, a.xid, a.pid, a.txn_start, a.lock_mode, a.relation as table_id,nvl(trim(c.”name”),d.relname) as tablename, a.granted,b.pid as blocking_pid ,datediff(s,a.txn_start,getdate())/86400||’ days ‘||datediff(s,a.txn_start,getdate())%86400/3600||’ hrs ‘||datediff(s,a.txn_start,getdate())%3600/60||’ mins ‘||datediff(s,a.txn_start,getdate())%60||’ secs’ as txn_duration
from svv_transactions a
left join (select pid,relation,granted from pg_locks group by 1,2,3) b
on a.relation=b.relation and a.granted=’f’ and b.granted=’t’
left join (select * from stv_tbl_perm where slice=0) c
on a.relation=c.id
left join pg_class d on a.relation=d.oid
where a.relation is not null;
Here’s a nice little blurb on how these blocking locks can happen (and they do with Redshift).
As far as allowing normal users to clean up blocking locks goes.
You could define a pl/pgsql stored procedure as a superuser – to release locks on a schema (to be safe hard code schema) then grant that to the logical owner of the schema.