【问题标题】:PostgreSQL - how to unlock table record AFTER shutdownPostgreSQL - 如何在关闭后解锁表记录
【发布时间】:2017-11-11 01:35:54
【问题描述】:

抱歉,我到处寻找,但找不到可行的解决方案:/ 我非常需要这个来进行异常测试。

我在这里尝试做的是:

  1. 在表 A 中插入行
  2. 锁定此记录
  3. (在单独的终端)服务 postgresql-9.6 停止
  4. 等一下
  5. (在单独的终端)服务 postgresql-9.6 启动
  6. “try”通过执行“COMMIT;”来解锁记录在与 #2 相同的终端中。

#2 我的做法是这样的:

BEGIN;
SELECT * FROM TABLE A WHERE X=Y FOR UPDATE;

问题是,一旦我执行了 #6,就会出现此错误:

DB=# commit;
FATAL:  terminating connection due to administrator command
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.

所以当我执行“COMMIT;”时同样,它只显示:

DB=# commit;
WARNING:  there is no transaction in progress
COMMIT

现在无法解锁记录。

我试过获取那个锁定的东西的 PID,然后执行 pg_terminate(或取消),但它不起作用。

DB=# select pg_class.relname,pg_locks.* from pg_class,pg_locks where pg_class.relfilenode=pg_locks.relation;
DB=# select pg_terminate_backend(2450);
FATAL:  terminating connection due to administrator command
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
DB=# select pg_cancel_backend(3417);
ERROR:  canceling statement due to user request

请帮忙。有没有人有任何想法? :/ ..或者这甚至可能吗?

我的规格:

  • Postgresql-9.6
  • 红帽 Linux

【问题讨论】:

    标签: postgresql


    【解决方案1】:

    这里有一个或三个基本误解。锁定状态不是持久的。

    当您锁定一条记录(或表)时,该锁与获取该锁的事务相关联。该事务是正在运行的 PostgreSQL 会话的一部分,即您与服务器的连接。

    在事务结束时释放锁。

    交易结束:

    • 在显式COMMIT 或ROLLBACK 上;
    • 当会话在没​​有明确COMMIT 的打开事务的情况下断开连接时,会触发隐含的ROLLBACK;
    • 当服务器关闭时,终止所有活动会话,再次触发所有正在进行的事务的隐含ROLLBACK。

    因此,当您在第 3 步关闭服务器时,您已释放在第 2 步获取的锁。获得该锁的事务不再存在,因为其会话已被服务器关闭终止。

    如果检查pg_locks,您将看到锁定的行在重新启动前是如何存在的,而在重新启动后又是如何消失的。

    【讨论】:

    • 我还要补充一点,除了您看到的与数据库的其他直接连接的行为之外,期望其他任何事情都是不现实的。它们将在数据库关闭时终止。
    • @Craig 感谢您的信息!所以基本上我的最终目标是错误的 xD 我们可能需要改进这个测试。我们计划围绕事务和锁定创建异常测试。你有关于你的答案细节的现有指南吗?或者我们可以在哪里找到这些?
    • @Bill 你说得很好。当我们从现在开始进行极其疯狂的测试时,我们会将其视为一种观点 xD
    • @thisNeil 我没有想到任何参考资料,但从关于事务、并发和隔离的 PostgreSQL 文档开始。您可以运行的最佳压力测试通常是“混乱猴子”式的测试,您可以在其中使用您的生产系统并随机破坏其下的东西,然后查看它的行为。
    • @Craig 不错。谢谢!肯定会查看 postgresql 文档。
    猜你喜欢
    • 2023-02-11
    • 2015-02-13
    • 2016-12-26
    • 1970-01-01
    • 2014-11-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多