J’ai une installation standard qui tente de restaurer une base de données. Elle échoue lors de la migration.
ALTER TABLE
Migration de la base de données...
EXCEPTION : rake db:migrate
Échec de la migration de la base de données.
rake avorté !
StandardError : Une erreur est survenue, ceci et toutes les migrations ultérieures sont annulées : (StandardError)
PG::DiskFull: ERREUR : impossible d'écrire dans le fichier « base/pgsql_tmp/pgsql_tmp11009.51 » : Plus d'espace disque disponible
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-4.0.1/lib/patches/db/pg/alias_method.rb:109:in `exec'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-4.0.1/lib/patches/db/pg/alias_method.rb:109:in `async_exec'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.4/lib/active_record/connection_adapters/postgresql/database_state
ments.rb:167:in `perform_query'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.4/lib/active_record/connection_adapters/abstract/database_stateme
nts.rb:556:in `block (2 levels) in raw_execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-8.0.4/lib/active_record/connection_adapters/abstract_adapter.rb:1017:in `block in with_raw_connection'
Il y a 90 Go de données libres sur le disque. Sur le disque source, le répertoire postgres ne fait que 23 Go.
Comment une base de données de 23 Go échoue-t-elle à être restaurée lors de la migration de la base de données avec 90 Go de libre ?
Après la restauration de la base de données, postgres_data faisait 24G.
Quelque chose dans la migration a fait gonfler postgres_data à 91G avant que le disque ne se remplisse et que la restauration n’échoue. Ceci est sur une installation propre avec les versions de Discourse indiquées ci-dessus.
Cela semble être un bug, je recatégorise donc. Je l’ai également constaté lors d’une tentative de mise à niveau. J’avais pensé que pour cette mise à niveau, une solution serait de migrer vers un nouveau serveur, mais je vois maintenant que cela ne fonctionnera pas.
Je suppose que la prochaine étape sera d’essayer de voir quelle requête cause cela et/ou quelle table est en cause. Je ne suis pas tout à fait sûr de la manière de procéder.
Je mets ceci dans le support, ce message provient directement du système de fichiers, si PG pense qu’il n’a pas d’espace, il n’a probablement pas d’espace car pas assez n’est alloué pour lui.
En utilisant du et df, j’ai observé la taille de postgres_data passer de 25g à 90g et l’espace sur le disque atteindre (presque) zéro avant qu’il ne tombe en panne.
Je suppose que j’ai besoin de trouver un moyen de suivre quelle requête est en cours d’exécution la prochaine fois.
Je l’ai vu sur au moins deux sites. Un lors d’une mise à niveau et un lors d’une restauration. Les deux avaient plus d’espace libre que la taille de la base de données au départ.
Un tas de migrations réécrivent des tables entières, ce qui peut temporairement utiliser plus d’espace, et PostgreSQL ne rend pas l’espace au système de manière agressive non plus.
Ce forum a-t-il l’IA avec des intégrations (embeddings) activée ?
Si vous voulez vous plonger dans les détails, vous pourriez le restaurer manuellement dans un environnement de développement correspondant au commit de mai 2025, puis passer au commit actuel et exécuter les migrations une par une, en affichant l’espace avant et après chacune — évidemment avec un script .
OK. Je restaure sur un site de production. Il est en cours de migration.
Voici une requête qui s’exécute depuis 30 minutes :
discourse=# SELECT pid, usename, state, query, query_start
FROM pg_stat_activity
WHERE state = 'active';
pid | usename | state | query | query_start
-----+-----------+--------+--------------------------------------------------------------------------------------------------------------+-------------------------------
519 | postgres | active | SELECT pid, usename, state, query, query_start +| 2026-02-14 17:58:35.473337+00
| | | FROM pg_stat_activity +|
| | | WHERE state = 'active'; |
308 | discourse | active | DELETE +| 2026-02-14 17:26:08.12598+00
| | | FROM calendar_events ce +|
| | | WHERE +|
| | | ce.id IN (SELECT DISTINCT(ce3.id) FROM calendar_events ce2 +|
| | | LEFT JOIN calendar_events ce3 ON ce3.user_id = ce2.user_id AND ce3.description = ce2.description+|
| | | WHERE ce2.start_date >= (ce3.start_date - INTERVAL '1 days') +|
| | | AND ce2.start_date <= (ce3.start_date + INTERVAL '1 days') +|
| | | AND ce2.timezone IS NOT NULL +|
| | | AND ce3.timezone IS NULL +|
| | | AND ce3.id != ce2.id +|
| | | AND ce2.post_id IS NULL +|
| | | AND ce3.post_id IS NULL +|
| | | ) +|
| | | |
(2 rows)
Ceci provient de ceci :
Cela montre que la dernière migration est plus récente, mais je suppose que c’est parce que cette migration provient d’un plugin qui vient d’être ajouté ;.
discourse=# SELECT version FROM schema_migrations ORDER BY version DESC LIMIT 1;
version
----------------
20250507013646
(1 row)
Il y a beaucoup d’événements de calendrier !!! 69_724_384 !
discourse=# select count(*) from calendar_events;
count
----------
69724384
(1 row)
Donc je suppose que c’est le problème.
. . . mais ils n’ont même pas discourse_calendar installé sur le site source !?
Mais ils ont bien ce nombre d’événements dans la table calendar_events sur la table source. . . .
.