'
[rails] /workspace/discourse/bin/pitchfork exited with code 0
--> Sending SIGTERM to other processes..
[ember] ./rolldown.mjs exited with code SIGTERM
discourse@ddf88cb78939:/workspace/discourse$
```
C’est peut-être une supposition, mais Discourse les confond-il ?
```plaintext
discourse@ddf88cb78939:/workspace/discourse$ sudo cat /shared/postgres_data/PG_VERSION
sudo cat /shared/postgres_data_orig/PG_VERSION
15
18
```
MODIFICATION : Résolu avec l’aide de ChatGPT. Je ne suis pas un expert en Linux/Postgres.
---
### Author:  [@kcahtoor](https://meta.discourse.org/u/kcahtoor)
#### Post date: [Août 10, 2026, 12:26 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/47 "2026-08-10T00:26:50Z")
Je rencontre un problème : PostgreSQL 18 est manquant ou ne migre pas ma base de données secondsite. Toute aide à ce sujet serait appréciée.
---
### Author:  [@chrisr](https://meta.discourse.org/u/chrisr)
#### Post date: [Août 10, 2026, 6:37 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/48 "2026-08-10T06:37:50Z")
J’ai une correction en attente pour les mises à jour multisites défectueuses, je vous tiendrai au courant quand ce sera prêt.
---
### Author:  [@chrisr](https://meta.discourse.org/u/chrisr)
#### Post date: [Août 10, 2026, 7:52 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/49 "2026-08-10T07:52:57Z")
Je viens de fusionner une correction pour les multisites, et toutes les bases de données devraient désormais être mises à niveau correctement. Vous pouvez rétablir votre base de données dans son état avant la mise à niveau et réessayer en procédant comme suit :
1. Vérifiez que les anciennes données existent toujours dans `/shared/postgres_data_old`.
2. Supprimez les données de la mise à niveau échouée dans `/shared/postgres_data` (si vous disposez d’espace disque suffisant, il peut être judicieux de les renommer pour l’instant plutôt que de les supprimer).
3. Renommez `/shared/postgres_data_old` en `/shared/postgres_data`. Vous devez également vous assurer que les permissions du dossier sont réglées sur 0700, sinon Postgres refusera de l’utiliser.
4. Relancez la mise à niveau en exécutant `./launcher rebuild app`.
---
### Author:  [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [Août 10, 2026, 8:40 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/50 "2026-08-10T08:40:36Z")
Je pense qu’ils ont résolu leur problème il y a quelques heures
> [@J'ai mis à jour vers la dernière version et j'ai tout perdu](https://meta.discourse.org/t/i-upgraded-to-latest-and-lost-everything/409647/5):
>
> J’ai donc vérifié le fichier de modèle PostgreSQL. Il ne cible qu’une seule base de données. C’est dingue. Il aurait dû parcourir les bases de données présentes et les modifier. Je laisse ceci ici pour quiconque cherche une solution dans ce scénario DB\_LIST=$(su postgres -c "/usr/lib/postgresql/${PG\_MAJOR\_OLD}/bin/psql -p 5432 -tAc \"select datname from pg\_database where not datistemplate and datname != 'postgres'\"") for DB in $DB\_LIST; do su postgres -c "/usr/lib/postgresql/${PG\_MAJOR\_OLD}…
---
### Author:  [@kcahtoor](https://meta.discourse.org/u/kcahtoor)
#### Post date: [Août 10, 2026, 9:03 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/51 "2026-08-10T09:03:21Z")
Merci, c’est très apprécié.
---
### Author:  [@peternlewis](https://meta.discourse.org/u/peternlewis)
#### Post date: [Août 11, 2026, 6:54 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/52 "2026-08-11T06:54:03Z")
J’ai remarqué ceci dans les messages de reconstruction :
116:C 11 Aug 2026 06:43:27.336 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see [vm.max\_map\_count growing steadily when vm.overcommit\_memory is 2 · Issue #1328 · jemalloc/jemalloc · GitHub](https://github.com/jemalloc/jemalloc/issues/1328). To fix this issue add ‘vm.overcommit\_memory = 1’ to /etc/sysctl.conf and then reboot or run the command ‘sysctl vm.overcommit\_memory=1’ for this to take effect.
Est-ce quelque chose dont je dois m’inquiéter ?
---
### Author:  [@peternlewis](https://meta.discourse.org/u/peternlewis)
#### Post date: [Août 11, 2026, 6:55 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/53 "2026-08-11T06:55:51Z")
Je remarque également que la taille de ma nouvelle base de données est nettement inférieure à l’ancienne :
```plaintext
root@Forum:/var/discourse/shared/standalone# du -sh postgres_data postures_data_old
6.8G postgres_data
10G postgres_data_old
17G total
```
Est-ce une source d’inquiétude ?
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [Août 11, 2026, 7:01 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/54 "2026-08-11T07:01:36Z")
> [@peternlewis](#):
>
> `postures_data_old`
C’est un nom de répertoire un peu étrange, non ?
Pour comparaison, voici ce que j’obtiens :
```plaintext
:/var/discourse/shared/data# du -sh postgres_data postgres_data_old
4.1G postgres_data
3.4G postgres_data_old
```
---
### Author:  [@peternlewis](https://meta.discourse.org/u/peternlewis)
#### Post date: [Août 11, 2026, 7:14 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/55 "2026-08-11T07:14:13Z")
> [@merefield](#):
>
> c’est un nom de répertoire un peu bizarre ?
Oui, je pense que la correction de type a quelque peu déformé cela. Il s’agit de `postgres_data`.
Donc, tes nouvelles données étaient plus volumineuses. C’est un peu inquiétant.
---
### Author:  [@Andrew\_Rowe](https://meta.discourse.org/u/Andrew_Rowe)
#### Post date: [Août 11, 2026, 2:38 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/56 "2026-08-11T14:38:00Z")
J’ai exécuté la mise à jour comme indiqué et tout s’est très bien passé. La première reconstruction a généré un message dans la console indiquant que la mise à jour depuis la version 15 avait réussi, ainsi que l’emplacement de l’ancienne base de données et les instructions pour exécuter une nouvelle reconstruction.
Merci à Lilly pour son indice
> [@Lilly](#):
>
> ```plaintext
> # vérifier la taille de la base de données
> du -sh /var/discourse/shared/data/postgres_data
>
> ```
j’ai pu voir que j’avais suffisamment d’espace sur le disque
EDIT : à ajouter
Merci à tous ceux qui ont travaillé à ce magnifique travail 👍
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [Août 11, 2026, 4:26 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/57 "2026-08-11T16:26:50Z")
> [@Lilly](#):
>
> ```plaintext
> # vérifier la taille de la base de données
> du -sh /var/discourse/shared/data/postgres_data
>
> ```
J’ajouterais probablement le caractère générique au cas où il resterait des vestiges de mises à niveau :
```plaintext
# vérifier la taille de la base de données
du -sh /var/discourse/shared/data/postgres_data*
```
---
### Author:  [@agemo](https://meta.discourse.org/u/agemo)
#### Post date: [Août 11, 2026, 5:24 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/58 "2026-08-11T17:24:14Z")
> [@Ed\_S](#):
>
> Quel type d’échec élégant (on l’espère) se produira s’il n’y a pas assez d’espace disque libre ? Quelqu’un finira bien par emprunter cette voie !
>
> Pour ceux qui n’ont pas assez d’espace disque libre, est-il possible de faire une sauvegarde, puis de la restaurer dans une installation fraîche, en guise de migration ?
>
> (Dans ce cas, ce serait aussi une bonne occasion de passer à une nouvelle version LTS du système d’exploitation. Ubuntu 26.04 est assez récent ; la version 26.04.1 devrait arriver très bientôt. Une installation fraîche du système d’exploitation sera peut-être moins problématique qu’une tentative de mise à niveau sur place.)
_vrrrmmmmmm_ 🚗 … 💥
Comme vous pouvez l’imaginer, je n’ai pas reçu ce mémo… zut !
---
### Author:  [@agemo](https://meta.discourse.org/u/agemo)
#### Post date: [Août 11, 2026, 5:26 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/59 "2026-08-11T17:26:59Z")
Eh bien, je n’avais aucune idée de cette mise à jour de la base de données et des exigences en matière d’espace. Un message d’erreur indiquant un manque de 12 Go d’espace sur PostgreSQL est apparu au départ, et l’application ne redémarrait pas. J’ai nettoyé le disque et réussi à libérer environ 6 Go, puis j’ai relancé l’opération, mais sans succès.
Je n’ai pas perdu de temps et suis revenu à une restauration à partir de la sauvegarde.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [Août 11, 2026, 5:54 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/60 "2026-08-11T17:54:15Z")
vous pouvez toujours faire un @pfaffman et migrer vers un serveur entièrement nouveau et commencer par une toute fraîche installation de PG 18 et la dernière version LTS d’Ubuntu pour booter …
---
### Author:  [@agemo](https://meta.discourse.org/u/agemo)
#### Post date: [Août 11, 2026, 10:54 UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/61 "2026-08-11T22:54:26Z")
Merci. Je vais effectuer une migration de test afin de vérifier :
> [@Ed\_S](#):
>
> Pour ceux qui n’ont pas assez d’espace disque libre, est-il possible de faire une sauvegarde, puis de la restaurer dans une installation fraîche, en guise de migration ?
Je garde un œil sur ce sujet.
[Previous page](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194.md?page=2)
[Next page](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194.md?page=4)