VectorChord requires its indexes to be reindexed when the extension is
updated. [1]
This commit adds functionality to save the current version of the
extension before performing an update, and then compare it with the
updated version to decide whether it should reindex Immich's indexes.
This complexity is needed to avoid reindexing every time PostgreSQL is
started, as it is an expensive operation that would slow down startup.
[1]: https://docs.immich.app/administration/postgres-standalone/#updating-vectorchord
The immich-machine-learning service can fail with
RuntimeError: Data processing error: I/O error: Operation not permitted (os error 1)
because huggingface attempts to download files to $HOME/.cache (which
doesn't exist in this case) unless $XDG_CACHE_HOME or $HF_HOME is set.
This enables VectorChord in the database (currently) alongside
pgvecto.rs. Note that VectorChord requires pgvector, which is enabled as
well by this option.
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
This avoids restarting the postgresql server, when only ensureDatabases
or ensureUsers have been changed. It will also allow to properly wait
for recovery to finish later.
To wait for "postgresql is ready" in other services, we now provide a
postgresql.target.
Resolves#400018
Co-authored-by: Marcel <me@m4rc3l.de>
`config.services.postgresql.package` is now only available when the
PostgreSQL module is actually enabled. If we're not using the local
database, we'll need to fallback to the latest postgresql version, since
we don't know about the remote version.
the redis module expects a user and group to exist with this name.
previously if there was no group with the same name as
`services.immich.user` the immich redis server would fail to start.
instead we can use the redis module's default behaviour: it will
create a user & group named "redis-immich".
