
是plsql的问题吗?,有张表就是打不开,问题如图,求大神解答。
展开全部
1、查询表是否存在锁postgreSQL的SQL为:
select a.locktype,a.database,a.pid,a.mode,a.relation,b.relname
from pg_locks a
join pg_class b on a.relation = b.oid
where upper(b.relname) = 'TABLE_NAME';
2、查询表锁及操作的SQL语句的SQL为:
select a.locktype,a.database,a.pid,a.mode,a.relation,b.relname,c.usename,c.current_query,c.query_start,c.client_addr
from pg_locks a
join pg_class b on a.relation = b.oid
join pg_stat_activity c on a.pid = c.procpid
where upper(b.relname) = 'TABLE_NAME';
不管是做应用开发,还是平时的基础数据库操作的时候,锁都是得必须注意的一个事情。
下面附上PG的表级锁简单介绍:
下面的列表显示了可用的锁模式和它们被 PostgreSQL 自动使用的场合。你也可以用 LOCK 命令明确获取这些锁。请注意所有这些锁模式都是表级锁,即使它们的名字包含"row"单词(这些名称是历史遗产)。从某种角度而言,这些名字反应了每种锁模式的典型用法,但是语意却都是一样的。两种锁模式之间真正的区别是它们有着不同的冲突锁集合。两个事务在同一时刻不能在同一个表上持有相互冲突的锁。不过,一个事务决不会和自身冲突。比如,它可以在一个表上请求 ACCESS EXCLUSIVE 然后接着请求 ACCESS SHARE 。非冲突锁模式可以被许多事务同时持有。请特别注意有些锁模式是自冲突的(比如,在任意时刻 ACCESS EXCLUSIVE 模式就不能够被多个事务拥有),但其它锁模式都不是自冲突的(比如,ACCESS SHARE 可以被多个事务持有)。
表级锁模式
ACCESS SHARE
只与 ACCESS EXCLUSIVE 冲突。
SELECT 命令在被引用的表上请求一个这种锁。通常,任何只读取表而不修改它的命令都请求这种锁模式。
ROW SHARE
与 EXCLUSIVE 和 ACCESS EXCLUSIVE 冲突。
SELECT FOR UPDATE 和 SELECT FOR SHARE 命令在目标表上需要一个这样模式的锁(加上在所有被引用但没有 ACCESS SHARE 的表上的 FOR UPDATE/FOR SHARE 锁)。
ROW EXCLUSIVE
与 SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE 冲突。
UPDATE, DELETE, INSERT 命令自动请求这个锁模式(加上所有其它被引用的表上的 ACCESS SHARE 锁)。通常,这种锁将被任何修改表中数据的查询请求。
SHARE UPDATE EXCLUSIVE
与 SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE 冲突。这个模式保护一个表不被并发模式改变和 VACUUM 。
VACUUM(不带 FULL选项), ANALYZE, CREATE INDEX CONCURRENTLY 请求这样的锁。
SHARE
与 ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE 冲突。这个模式避免表的并发数据修改。
CREATE INDEX(不带 CONCURRENTLY 选项)语句要求这样的锁模式。
SHARE ROW EXCLUSIVE
与 ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE 冲突。
任何 PostgreSQL 命令都不会自动请求这个锁模式。
EXCLUSIVE
与 ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE 冲突。这个模式只允许并发 ACCESS SHARE 锁,也就是说,只有对表的读动作可以和持有这个锁模式的事务并发执行。
任何 PostgreSQL 命令都不会在用户表上自动请求这个锁模式。不过,在某些操作的时候,会在某些系统表上请求它。
ACCESS EXCLUSIVE
与与所有模式冲突(包括其自身)。这个模式保证其所有者(事务)是可以访问该表的唯一事务。
ALTER TABLE, DROP TABLE, TRUNCATE, REINDEX, CLUSTER, VACUUM FULL 命令要求这样的锁。在 LOCK TABLE 命令没有明确声明需要的锁模式时,它是缺省锁模式。
【提示】只有 ACCESS EXCLUSIVE 阻塞 SELECT(不包含 FOR UPDATE/SHARE 语句)。
一旦请求已获得某种锁,那么该锁模式将持续到事务结束。但是如果在建立保存点之后才获得锁,那么在回滚到这个保存点的时候将立即释放所有该保存点之后获得的锁。这与 ROLLBACK 取消所有保存点之后对表的影响的原则一致。同样的原则也适用于 PL/pgSQL 异常块中获得的锁:一个跳出块的错误将释放在块中获得的锁。
select a.locktype,a.database,a.pid,a.mode,a.relation,b.relname
from pg_locks a
join pg_class b on a.relation = b.oid
where upper(b.relname) = 'TABLE_NAME';
2、查询表锁及操作的SQL语句的SQL为:
select a.locktype,a.database,a.pid,a.mode,a.relation,b.relname,c.usename,c.current_query,c.query_start,c.client_addr
from pg_locks a
join pg_class b on a.relation = b.oid
join pg_stat_activity c on a.pid = c.procpid
where upper(b.relname) = 'TABLE_NAME';
不管是做应用开发,还是平时的基础数据库操作的时候,锁都是得必须注意的一个事情。
下面附上PG的表级锁简单介绍:
下面的列表显示了可用的锁模式和它们被 PostgreSQL 自动使用的场合。你也可以用 LOCK 命令明确获取这些锁。请注意所有这些锁模式都是表级锁,即使它们的名字包含"row"单词(这些名称是历史遗产)。从某种角度而言,这些名字反应了每种锁模式的典型用法,但是语意却都是一样的。两种锁模式之间真正的区别是它们有着不同的冲突锁集合。两个事务在同一时刻不能在同一个表上持有相互冲突的锁。不过,一个事务决不会和自身冲突。比如,它可以在一个表上请求 ACCESS EXCLUSIVE 然后接着请求 ACCESS SHARE 。非冲突锁模式可以被许多事务同时持有。请特别注意有些锁模式是自冲突的(比如,在任意时刻 ACCESS EXCLUSIVE 模式就不能够被多个事务拥有),但其它锁模式都不是自冲突的(比如,ACCESS SHARE 可以被多个事务持有)。
表级锁模式
ACCESS SHARE
只与 ACCESS EXCLUSIVE 冲突。
SELECT 命令在被引用的表上请求一个这种锁。通常,任何只读取表而不修改它的命令都请求这种锁模式。
ROW SHARE
与 EXCLUSIVE 和 ACCESS EXCLUSIVE 冲突。
SELECT FOR UPDATE 和 SELECT FOR SHARE 命令在目标表上需要一个这样模式的锁(加上在所有被引用但没有 ACCESS SHARE 的表上的 FOR UPDATE/FOR SHARE 锁)。
ROW EXCLUSIVE
与 SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE 冲突。
UPDATE, DELETE, INSERT 命令自动请求这个锁模式(加上所有其它被引用的表上的 ACCESS SHARE 锁)。通常,这种锁将被任何修改表中数据的查询请求。
SHARE UPDATE EXCLUSIVE
与 SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE 冲突。这个模式保护一个表不被并发模式改变和 VACUUM 。
VACUUM(不带 FULL选项), ANALYZE, CREATE INDEX CONCURRENTLY 请求这样的锁。
SHARE
与 ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE 冲突。这个模式避免表的并发数据修改。
CREATE INDEX(不带 CONCURRENTLY 选项)语句要求这样的锁模式。
SHARE ROW EXCLUSIVE
与 ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE 冲突。
任何 PostgreSQL 命令都不会自动请求这个锁模式。
EXCLUSIVE
与 ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE 冲突。这个模式只允许并发 ACCESS SHARE 锁,也就是说,只有对表的读动作可以和持有这个锁模式的事务并发执行。
任何 PostgreSQL 命令都不会在用户表上自动请求这个锁模式。不过,在某些操作的时候,会在某些系统表上请求它。
ACCESS EXCLUSIVE
与与所有模式冲突(包括其自身)。这个模式保证其所有者(事务)是可以访问该表的唯一事务。
ALTER TABLE, DROP TABLE, TRUNCATE, REINDEX, CLUSTER, VACUUM FULL 命令要求这样的锁。在 LOCK TABLE 命令没有明确声明需要的锁模式时,它是缺省锁模式。
【提示】只有 ACCESS EXCLUSIVE 阻塞 SELECT(不包含 FOR UPDATE/SHARE 语句)。
一旦请求已获得某种锁,那么该锁模式将持续到事务结束。但是如果在建立保存点之后才获得锁,那么在回滚到这个保存点的时候将立即释放所有该保存点之后获得的锁。这与 ROLLBACK 取消所有保存点之后对表的影响的原则一致。同样的原则也适用于 PL/pgSQL 异常块中获得的锁:一个跳出块的错误将释放在块中获得的锁。
更多追问追答
追问
具体该怎么做呢
追答
你命令输入进去,有没有看到表给锁了
本回答被提问者采纳
已赞过
已踩过<
评论
收起
你对这个回答的评价是?

2022-08-05 广告
苏州蓝晓生物科技有限公司。标准化核心产品:公司拥有完整的琼脂糖介质、葡聚糖介质、聚甲基丙烯酸酯介质生产线,年产分离介质50000L,产品质量稳定并达到国际领先水平。核心优势:公司核心技术人员拥有近二十年不同基质的基球开发和官能化的丰富技术经...
点击进入详情页
本回答由苏州蓝晓生物科技有限公司_提供
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询