immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-07-25 14:00:45 +03:00
Code Issues 783 Packages Projects Releases 22 Wiki Activity

PostgresError: relation "kysely_migrations_lock" does not exist #6355

New Issue
Closed
opened 2026-02-05 12:13:32 +03:00 by OVERLORD · 4 comments
OVERLORD commented 2026-02-05 12:13:32 +03:00
Owner
Copy Link

Originally created by @pando85 on GitHub (Jun 23, 2025).

I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.

  • Yes

The bug

after updating from 1.34.0 to 1.35.2 I got this error:

[Nest] 16  - 06/23/2025, 9:35:40 AM   ERROR [Api:DatabaseRepository] Kysely migrations failed: PostgresError: relation "kysely_migrations_lock" does not exist
PostgresError: relation "kysely_migrations_lock" does not exist
    at ErrorResponse (/usr/src/app/node_modules/postgres/cjs/src/connection.js:790:26)
    at handle (/usr/src/app/node_modules/postgres/cjs/src/connection.js:476:6)
    at TLSSocket.data (/usr/src/app/node_modules/postgres/cjs/src/connection.js:315:9)
    at TLSSocket.emit (node:events:518:28)
    at addChunk (node:internal/streams/readable:561:12)
    at readableAddChunkPushByteMode (node:internal/streams/readable:512:3)
    at Readable.push (node:internal/streams/readable:392:5)
    at TLSWrap.onStreamRead (node:internal/stream_base_commons:189:23) {
  severity_local: 'ERROR',
  severity: 'ERROR',
  code: '42P01',
  position: '18',
  file: 'parse_relation.c',
  line: '1449',
  routine: 'parserOpenTable'
}
api worker exited with code 1

I discovered that the table was there but the search_path looks like this:

immich=# SHOW search_path;
  search_path
---------------
 "$user", data
(1 row)

I had to change it back to:

immich=# ALTER DATABASE immich SET search_path TO public, "$user";
ALTER DATABASE

I'm not sure if it's a bug related to the migrations. I couldn't find anything relevant in the migrations code from server/src/migrations.

Anyway, as I haven't changed anything during the last two weeks, except for the version I wanted to post, I'm posting it here as closed, in case anyone finds this useful.

The OS that Immich Server is running on

Ubuntu 24.04

Version of Immich Server

v1.135.3

Version of Immich Mobile App

v1.34.0

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

Kubernetes: https://github.com/pando85/homelab/blob/28f473b0f2527a85878bea009ac026bdb231ffa6/apps/immich/values.yaml

Your .env content

It is in the setup.

Reproduction steps

...

Relevant log output

Additional information

No response

Originally created by @pando85 on GitHub (Jun 23, 2025). ### I have searched the existing issues, both open and closed, to make sure this is not a duplicate report. - [x] Yes ### The bug after updating from 1.34.0 to 1.35.2 I got this error: ``` [Nest] 16 - 06/23/2025, 9:35:40 AM ERROR [Api:DatabaseRepository] Kysely migrations failed: PostgresError: relation "kysely_migrations_lock" does not exist PostgresError: relation "kysely_migrations_lock" does not exist at ErrorResponse (/usr/src/app/node_modules/postgres/cjs/src/connection.js:790:26) at handle (/usr/src/app/node_modules/postgres/cjs/src/connection.js:476:6) at TLSSocket.data (/usr/src/app/node_modules/postgres/cjs/src/connection.js:315:9) at TLSSocket.emit (node:events:518:28) at addChunk (node:internal/streams/readable:561:12) at readableAddChunkPushByteMode (node:internal/streams/readable:512:3) at Readable.push (node:internal/streams/readable:392:5) at TLSWrap.onStreamRead (node:internal/stream_base_commons:189:23) { severity_local: 'ERROR', severity: 'ERROR', code: '42P01', position: '18', file: 'parse_relation.c', line: '1449', routine: 'parserOpenTable' } api worker exited with code 1 ``` I discovered that the table was there but the search_path looks like this: ``` immich=# SHOW search_path; search_path --------------- "$user", data (1 row) ``` I had to change it back to: ``` immich=# ALTER DATABASE immich SET search_path TO public, "$user"; ALTER DATABASE ``` I'm not sure if it's a bug related to the migrations. I couldn't find anything relevant in the migrations code from `server/src/migrations`. Anyway, as I haven't changed anything during the last two weeks, except for the version I wanted to post, I'm posting it here as closed, in case anyone finds this useful. ### The OS that Immich Server is running on Ubuntu 24.04 ### Version of Immich Server v1.135.3 ### Version of Immich Mobile App v1.34.0 ### Platform with the issue - [x] Server - [ ] Web - [ ] Mobile ### Your docker-compose.yml content ```YAML Kubernetes: https://github.com/pando85/homelab/blob/28f473b0f2527a85878bea009ac026bdb231ffa6/apps/immich/values.yaml ``` ### Your .env content ```Shell It is in the setup. ``` ### Reproduction steps 1. 2. 3. ... ### Relevant log output ```shell ``` ### Additional information _No response_
OVERLORD added the 🗄️server label 2026-02-05 12:13:32 +03:00
OVERLORD commented 2026-02-05 12:13:35 +03:00
Author
Owner
Copy Link

@mmomjian commented on GitHub (Jun 23, 2025):

This was discussed in #19436. I am not confident that the fix in #19392 / #19462 would prevent this, so re opening for now.

Can you run select * from pg_db_role_setting; ?

@mmomjian commented on GitHub (Jun 23, 2025): This was discussed in #19436. I am not confident that the fix in #19392 / #19462 would prevent this, so re opening for now. Can you run `select * from pg_db_role_setting;` ?
OVERLORD commented 2026-02-05 12:13:36 +03:00
Author
Owner
Copy Link

@pando85 commented on GitHub (Jun 23, 2025):

That looks bad:

immich=# select * from pg_db_role_setting;
 setdatabase | setrole |            setconfig
-------------+---------+---------------------------------
           0 |   16731 | {"search_path=\"$user\", data"}
           0 |   16733 | {"search_path=\"$user\", data"}
           0 |   16735 | {"search_path=\"$user\", data"}
           0 |   16738 | {"search_path=\"$user\", data"}
           0 |   16740 | {"search_path=\"$user\", data"}
           0 |   16742 | {"search_path=\"$user\", data"}
@pando85 commented on GitHub (Jun 23, 2025): That looks bad: ``` immich=# select * from pg_db_role_setting; setdatabase | setrole | setconfig -------------+---------+--------------------------------- 0 | 16731 | {"search_path=\"$user\", data"} 0 | 16733 | {"search_path=\"$user\", data"} 0 | 16735 | {"search_path=\"$user\", data"} 0 | 16738 | {"search_path=\"$user\", data"} 0 | 16740 | {"search_path=\"$user\", data"} 0 | 16742 | {"search_path=\"$user\", data"} ```
OVERLORD commented 2026-02-05 12:13:37 +03:00
Author
Owner
Copy Link

@applikata commented on GitHub (Jul 12, 2025):

I encountered the same error. Fixed for me.
Thank you very much

@applikata commented on GitHub (Jul 12, 2025): I encountered the same error. Fixed for me. Thank you very much
OVERLORD commented 2026-02-05 12:13:37 +03:00
Author
Owner
Copy Link

@jrasm91 commented on GitHub (Sep 9, 2025):

We tried to automatically fix/correct this, but you will just have to manually update the search path to include the namespace that includes the immich database.

@jrasm91 commented on GitHub (Sep 9, 2025): We tried to automatically fix/correct this, but you will just have to manually update the search path to include the namespace that includes the immich database.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:skip
changelog:translation
cli
date-time
dependencies
documentation
external-library
format
good first issue
mobile-beta
mobile-beta
mobile-beta
needs-answer
nice to have
pull-request
Mirrored from GitHub Pull Request
 sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label 🗄️server
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#6355
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?