Arch Linux User Repository

PostgreSQL 18 is coming to the Arch repos. Before upgrading, backup the files for vectorchord and pgvector somewhere, and then follow https://wiki.archlinux.org/title/PostgreSQL#Upgrading_PostgreSQL instructions. (In the next release, I'll also update the postinstall message to recommend changing postgresql.conf instead of doing ALTER SYSTEM SET.)

Also, you may find yourself updating VectorChord in this process. When doing so, remember to follow the migration steps at https://docs.immich.app/administration/postgres-standalone/#updating-vectorchord .

immich-web (localhost/immich-server:2283) used to be broken for some users of this package.

As @yparitcher also noticed, this was most likely caused by the following additions to .gitignore from f4e0aad2c495, which have since be reverted:

src/
pkg/
*.pkg.tar.zst
LICENSES/

The reason—for both this change sometimes and unpredictably breaking the build, and builds under a clean chroot still working—is unknown. I meant to investigate this on 2025-08-19 while updating the package but called it a day due to the unpredictability and long time of building. Help with figuring out why this happened would be greatly appreciated.

You may notice pacman refuse to upgrade this package, saying warning: cannot resolve "vectorchord", a dependency of "immich-server".

This is due to required manual intervention within the immich server database.

Newer versions of immich server have deprecated pgvecto.rs in favor of vectorchord.

Before updating from 1.133.1 or older, please follow steps 1 and 2 of the manual migration steps (should be the second dropdown) at https://immich.app/docs/administration/postgres-standalone/#migrating-to-vectorchord and uninstall pgvecto.rs.

Remember to remove references to "vectors.so" (which is shipped by pgvecto.rs) in shared_preload_libraries before pgvecto.rs in uninstalled. (For vectorchord to work, you'll need to add "vchord.so" to shared_preload_libraries after the upgrade as well.)

After that, you may upgrade this package. Please remember to follow steps 4 and 5 of the manual migration steps after the upgrade is finished to prevent data loss.

Hi there, I finally ended up rebuilding the database, but I now understand how this thing with the postgres libraries work. Now I think I'll be ready for the next db upgrade. Thanks everyone!

I can see that. :) I'm trying now to understand how to adjust that so that makepkg -si can take some environment variable or setting into account. EDIT: figured that one out. edited original post. another error follows about tsconfig.json but it may not be critical.

Looks like you simply ran out of memory allocation: https://stackoverflow.com/questions/38558989/node-js-heap-out-of-memory

For me, this is thrown during the web build, which results in a broken webclient UI that doesn't load. This is, however, using yay, so I'll retry with a manual package build and install. EDIT: manual package build also fails with same EDIT: this error was rectified by executing: export NODE_OPTIONS=--max-old-space-size=4096 before makepkg -si

<--- Last few GCs --->
│ [74890:0x55e521122000]    59003 ms: Mark-Compact (reduce) 1912.2 (1928.8) -> 1908.6 (1925.8) MB, pooled: 0.0 MB, 32.15 / 0.08 ms (+ 2317.2 ms in 1093 steps since start of marking, biggest step 109.0 ms, walltime since start of marking 2506 ms) (average mu
│ FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
│ ----- Native stack trace -----
│  1: 0x55e5191e8745 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node]
│  2: 0x55e519769144  [node]
│  3: 0x55e51976924b  [node]
│  4: 0x55e5199f451c  [node]
│  5: 0x55e5199fa906  [node]
│  6: 0x55e5199faa17  [node]
│  7: 0x55e519a0a2c4  [node]
│  8: 0x55e519a0d714  [node]
│  9: 0x55e51a481347  [node]
│ 10: 0x55e519a0ac48  [node]
│ 11: 0x55e519a0f415  [node]
│ 12: 0x55e519508b39 node::PerIsolatePlatformData::RunForegroundTask(std::unique_ptr<v8::Task, std::default_delete<v8::Task> >) [node]
│ 13: 0x55e51950b598 node::PerIsolatePlatformData::FlushForegroundTasksInternal() [node]
│ 14: 0x7fcd7b766ec3  [/usr/lib/libuv.so.1]
│ 15: 0x7fcd7b7860a1  [/usr/lib/libuv.so.1]
│ 16: 0x7fcd7b76d5a2 uv_run [/usr/lib/libuv.so.1]
│ 17: 0x55e51931fdd3 node::SpinEventLoopInternal(node::Environment*) [node]
│ 18: 0x55e5194c14ba node::NodeMainInstance::Run(node::ExitCode*, node::Environment*) [node]
│ 19: 0x55e5194c1aed node::NodeMainInstance::Run() [node]
│ 20: 0x55e5193f8ee0 node::Start(int, char**) [node]
│ 21: 0x7fcd79e27675  [/usr/lib/libc.so.6]
│ 22: 0x7fcd79e27729 __libc_start_main [/usr/lib/libc.so.6]
│ 23: 0x55e51931b955 _start [node]
└─ Failed in 1m 29.3s at /home/######/.cache/yay/immich/src/immich-2.2.3/web
/home/######/.cache/yay/immich/src/immich-2.2.3/web:
 ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL  immich-web@2.2.3 build: `vite build`
Command failed with signal "SIGABRT"

@caoticofanegas copy the files listed under pacman -Ql vectorchord and pacman -Ql pgvector under the relevant directories under /opt/pgsql-17

@caoticofanegas

Check the wiki, though the writing may be a little convoluted. Did you update before running pg_dumpall? Then you need to copy the extensions over to the old cluster's server.

Okay, so thanks to your encouragement, I'm back trying to upgrade the database to psql18. I'm stuck at the same point though, I get an error while doing the pg_upgrade step. It tells me to check a logfile, and this is what I found that is relevant:

pg_dump: error: la consulta falló: ERROR:  could not access file "$libdir/vchord": No such file or directory

I don't know where to find that file or directory, or where to link it to.

Any idea?

EDIT: Found /usr/lib/postgresql/vchord.so, but I still don't know what to do with it.

EDIT2: I just remembered that trying to fix this, someone suggested to modify the file postgresql.auto.conf and comment out the shared_preload_libraries line. I've uncommented back that line, and now pg_upgrade fails to start the psql-17 server:

waiting for server to start....2025-11-07 15:20:56.942 CET [6099] FATAL:
 could not access file "vchord.so": No such file or directory

Looks loke that was important after all.

@caoticofanegas I actually find the dump/restore method much less error prone, and it is the way I always upgraded postgresql without any issue. also a good opportunity for maintenance / clean-up, if using it for multiple services.

Hi everyone, sorry I was out for a few days, and thanks for your comments. I think I messed up the vectorchord part, so up_upgrade failed miserably. Anyway, I changed the machine learning model a month ago or so, so immich had to rebuild everything again and it was't much of a pain, so I think I'll just try and do it again with a new db. I'll keep you posted if I find anything interesting to improve the package.

Thanks again!