我知道这不是OP的问题，但我最近遇到了这个问题，原因不同。作为参考，我在SQL Server上使用了Liquibase Maven插件(Liquibase - Maven -plugin:3.1.1)。

Anyway, I'd erroneously copied and pasted a SQL Server "use" statement into one of my scripts that switches databases, so liquibase was running and updating the DATABASECHANGELOGLOCK, acquiring the lock in the correct database, but then switching databases to apply the changes. Not only could I NOT see my changes or liquibase audit in the correct database, but of course, when I ran liquibase again, it couldn't acquire the lock, as the lock had been released in the "wrong" database, and so was still locked in the "correct" database. I'd have expected liquibase to check the lock was still applied before releasing it, and maybe that is a bug in liquibase (I haven't checked yet), but it may well be addressed in later versions! That said, I suppose it could be considered a feature!

我知道，这是一个学生的错误，但我在这里提出这个问题，以防有人遇到同样的问题!

问题是在Liquibase中执行SequenceExists有bug。因为包含这些语句的变更集花费了很长时间，并且意外地中止了。然后，下一次尝试执行liquibase脚本时，锁被持有。

  <changeSet author="user" id="123">
    <preConditions onFail="CONTINUE">
      <not><sequenceExists sequenceName="SEQUENCE_NAME_SEQ" /></not>
    </preConditions>
    <createSequence sequenceName="SEQUENCE_NAME_SEQ"/>
  </changeSet>

一个解决方法是使用纯SQL来检查这个:

  <changeSet author="user" id="123">
    <preConditions onFail="CONTINUE">
            <sqlCheck expectedResult="0">
              select count(*) from user_sequences where sequence_name = 'SEQUENCE_NAME_SEQ';
            </sqlCheck>
    </preConditions>
    <createSequence sequenceName="SEQUENCE_NAME_SEQ"/>
  </changeSet>

Lockdata存储在DATABASECHANGELOCK表中。要摆脱锁，只需将1更改为0或删除该表并重新创建。

有时，如果更新应用程序突然停止，那么锁仍然卡住。

然后运行

UPDATE DATABASECHANGELOGLOCK SET LOCKED=0, LOCKGRANTED=null, LOCKEDBY=null where ID=1;

对数据库有帮助。

你可能还需要将LOCKED=0替换为LOCKED=FALSE。

或者您可以简单地删除DATABASECHANGELOGLOCK表，它将被重新创建。

我知道这不是OP的问题，但我最近遇到了这个问题，原因不同。作为参考，我在SQL Server上使用了Liquibase Maven插件(Liquibase - Maven -plugin:3.1.1)。

Anyway, I'd erroneously copied and pasted a SQL Server "use" statement into one of my scripts that switches databases, so liquibase was running and updating the DATABASECHANGELOGLOCK, acquiring the lock in the correct database, but then switching databases to apply the changes. Not only could I NOT see my changes or liquibase audit in the correct database, but of course, when I ran liquibase again, it couldn't acquire the lock, as the lock had been released in the "wrong" database, and so was still locked in the "correct" database. I'd have expected liquibase to check the lock was still applied before releasing it, and maybe that is a bug in liquibase (I haven't checked yet), but it may well be addressed in later versions! That said, I suppose it could be considered a feature!

我知道，这是一个学生的错误，但我在这里提出这个问题，以防有人遇到同样的问题!

在postgres 12中，我需要使用这个命令:

UPDATE DATABASECHANGELOGLOCK SET LOCKED=false, LOCKGRANTED=null, LOCKEDBY=null where ID=1;

您可以手动或使用query安全地删除表。它将被自动重新创建。

DROP TABLE DATABASECHANGELOGLOCK;