Migration Lock in database -- any way to clean up? #290

New Issue

OVERLORD · 2026-02-04T18:24:19+03:00

OVERLORD commented

2026-02-04 18:24:19 +03:00

Originally created by @swcurran on GitHub (Feb 10, 2023).

It looks like I've got a problem in my Planka database on my local deploy. Is there an easy way to clean this up, or am I stuck? Naturally, I've not been taking backups... 🦤

Thanks

After a docker restart, here is what I get in the logs (via docker logs).

Node.js v18.12.1
Tried 1 times. Waiting 5 seconds...
/app/node_modules/pg-protocol/dist/parser.js:287
        const message = name === 'notice' ? new messages_1.NoticeMessage(length, messageValue) : new messages_1.DatabaseError(messageValue, length, name);
                                                                                                 ^

error: select * from "migration_lock" - MultiXactId 2 has not been created yet -- apparent wraparound
    at Parser.parseErrorMessage (/app/node_modules/pg-protocol/dist/parser.js:287:98)
    at Parser.handlePacket (/app/node_modules/pg-protocol/dist/parser.js:126:29)
    at Parser.parse (/app/node_modules/pg-protocol/dist/parser.js:39:38)
    at Socket.<anonymous> (/app/node_modules/pg-protocol/dist/index.js:11:42)
    at Socket.emit (node:events:513:28)
    at addChunk (node:internal/streams/readable:324:12)
    at readableAddChunk (node:internal/streams/readable:297:9)
    at Readable.push (node:internal/streams/readable:234:10)
    at TCP.onStreamRead (node:internal/stream_base_commons:190:23) {
  length: 131,
  severity: 'ERROR',
  code: 'XX000',
  detail: undefined,
  hint: undefined,
  position: undefined,
  internalPosition: undefined,
  internalQuery: undefined,
  where: undefined,
  schema: undefined,
  table: undefined,
  column: undefined,
  dataType: undefined,
  constraint: undefined,
  file: 'multixact.c',
  line: '1304',
  routine: 'GetMultiXactIdMembers'
}

Originally created by @swcurran on GitHub (Feb 10, 2023). It looks like I've got a problem in my Planka database on my local deploy. Is there an easy way to clean this up, or am I stuck? Naturally, I've not been taking backups... 🦤 Thanks After a docker restart, here is what I get in the logs (via `docker logs`). ``` Node.js v18.12.1 Tried 1 times. Waiting 5 seconds... /app/node_modules/pg-protocol/dist/parser.js:287 const message = name === 'notice' ? new messages_1.NoticeMessage(length, messageValue) : new messages_1.DatabaseError(messageValue, length, name); ^ error: select * from "migration_lock" - MultiXactId 2 has not been created yet -- apparent wraparound at Parser.parseErrorMessage (/app/node_modules/pg-protocol/dist/parser.js:287:98) at Parser.handlePacket (/app/node_modules/pg-protocol/dist/parser.js:126:29) at Parser.parse (/app/node_modules/pg-protocol/dist/parser.js:39:38) at Socket.<anonymous> (/app/node_modules/pg-protocol/dist/index.js:11:42) at Socket.emit (node:events:513:28) at addChunk (node:internal/streams/readable:324:12) at readableAddChunk (node:internal/streams/readable:297:9) at Readable.push (node:internal/streams/readable:234:10) at TCP.onStreamRead (node:internal/stream_base_commons:190:23) { length: 131, severity: 'ERROR', code: 'XX000', detail: undefined, hint: undefined, position: undefined, internalPosition: undefined, internalQuery: undefined, where: undefined, schema: undefined, table: undefined, column: undefined, dataType: undefined, constraint: undefined, file: 'multixact.c', line: '1304', routine: 'GetMultiXactIdMembers' } ```

OVERLORD closed this issue

2026-02-04 18:24:27 +03:00

OVERLORD commented

2026-02-04 18:24:30 +03:00

@meltyshev commented on GitHub (Feb 10, 2023):

Hi! I've never encountered this error. It seems to be some bug in Postgres, trying to find how to solve it...

@meltyshev commented on GitHub (Feb 10, 2023): Hi! I've never encountered this error. It seems to be some bug in Postgres, trying to find how to solve it...

OVERLORD commented

2026-02-04 18:24:36 +03:00

@nickbe commented on GitHub (Feb 10, 2023):

The reason for this is most likey some hardware or file system related problem. This could also be caused by an antivirus software.

Check your file system for errors and check if your computer lost power suddenly in the past. But I'm afraid the only thing you can do is restore the database from the latest backup.

@nickbe commented on GitHub (Feb 10, 2023): The reason for this is most likey some hardware or file system related problem. This could also be caused by an antivirus software. Check your file system for errors and check if your computer lost power suddenly in the past. But I'm afraid the only thing you can do is restore the database from the latest backup.

OVERLORD commented

2026-02-04 18:24:37 +03:00

@meltyshev commented on GitHub (Feb 10, 2023):

You can also try to recreate the migration_lock table (but maybe the problem is not in this table at all):

CREATE TABLE migration_lock_copy (LIKE migration_lock);
DROP TABLE migration_lock;
ALTER TABLE migration_lock_copy RENAME TO migration_lock;
INSERT INTO migration_lock VALUES (1, 0);

I also found this way to copy data from a corrupted table:

CREATE TABLE user_account_copy (LIKE user_account);

DO
$$DECLARE
   c CURSOR FOR SELECT * FROM user_account;
   r user_account;
   cnt bigint := 0;
BEGIN
   OPEN c;

   LOOP
      cnt := cnt + 1;

      /* block to start a subtransaction for each row */
      BEGIN
         FETCH c INTO r;

         EXIT WHEN NOT FOUND;
      EXCEPTION
         WHEN OTHERS THEN
            /* there was data corruption fetching the row */
            RAISE WARNING 'skipped corrupt data at row number %', cnt;

            MOVE c;

            CONTINUE;
      END;

      /* row is good, salvage it */
      INSERT INTO user_account_copy VALUES (r.*);
   END LOOP;
END;$$;

DROP TABLE user_account;
ALTER TABLE user_account_copy RENAME TO user_account;

Probably it should be done with all tables.

@meltyshev commented on GitHub (Feb 10, 2023): You can also try to recreate the `migration_lock` table (but maybe the problem is not in this table at all): ``` CREATE TABLE migration_lock_copy (LIKE migration_lock); DROP TABLE migration_lock; ALTER TABLE migration_lock_copy RENAME TO migration_lock; INSERT INTO migration_lock VALUES (1, 0); ``` I also found this way to copy data from a corrupted table: ``` CREATE TABLE user_account_copy (LIKE user_account); DO $$DECLARE c CURSOR FOR SELECT * FROM user_account; r user_account; cnt bigint := 0; BEGIN OPEN c; LOOP cnt := cnt + 1; /* block to start a subtransaction for each row */ BEGIN FETCH c INTO r; EXIT WHEN NOT FOUND; EXCEPTION WHEN OTHERS THEN /* there was data corruption fetching the row */ RAISE WARNING 'skipped corrupt data at row number %', cnt; MOVE c; CONTINUE; END; /* row is good, salvage it */ INSERT INTO user_account_copy VALUES (r.*); END LOOP; END;$$; DROP TABLE user_account; ALTER TABLE user_account_copy RENAME TO user_account; ``` Probably it should be done with all tables.

OVERLORD commented

2026-02-04 18:24:41 +03:00

@swcurran commented on GitHub (Feb 10, 2023):

Thanks — I’ll let you know how it goes. Much appreciated!

@swcurran commented on GitHub (Feb 10, 2023): Thanks — I’ll let you know how it goes. Much appreciated!

OVERLORD commented

2026-02-04 18:24:58 +03:00

@swcurran commented on GitHub (Feb 10, 2023):

I used the first script (below) and it worked — nice! Thanks so much. Closing this issue and submit a sponsor transaction!

CREATE TABLE migration_lock_copy (LIKE migration_lock);
DROP TABLE migration_lock;
ALTER TABLE migration_lock_copy RENAME TO migration_lock;
INSERT INTO migration_lock VALUES (1, 0);

@swcurran commented on GitHub (Feb 10, 2023): I used the first script (below) and it worked — nice! Thanks so much. Closing this issue and submit a sponsor transaction! ``` CREATE TABLE migration_lock_copy (LIKE migration_lock); DROP TABLE migration_lock; ALTER TABLE migration_lock_copy RENAME TO migration_lock; INSERT INTO migration_lock VALUES (1, 0); ```

OVERLORD commented

2026-02-04 18:24:59 +03:00

@meltyshev commented on GitHub (Feb 10, 2023):

Very glad it worked! And thank you very much for the support 🙏

@meltyshev commented on GitHub (Feb 10, 2023): Very glad it worked! And thank you very much for the support 🙏

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/planka#290