Vous n'êtes pas identifié(e).
Ce message indique une corruption dans le fichier global/pg_control, fichier qui contient des informations critiques sur l'instance et notamment à partir d'où rejouer les données en cas d'arrêt brutal.
Si ce fichier est corrompu il n'est pas possible de démarrer l'instance sans perdre ou corrompre des données. Mais plus grave que ça, ce fichier est tellement critique qu'il contient moins de 512 octets, c'est-à-dire suffisament petit pour tenir sur un bloc physique d'un disque et donc garantir des écritures atomiques. Si ce fichier est corrompu, il est à peu près sûr qu'il y a eu un gros problème sur les disques et que le reste des données a également souffert, et qu'il n'y a pas grand chose à récupérer. Votre meilleur espoir est de repartir depuis votre sauvegarde la plus récente.
Il nous faut plus de détail que "il y avais un problème avec le checksum data" pour pouvoir vous aider. Pouvez-vous préciser la version de postgres (version 13 j'imagine, mais quelle version mineure ?), la liste des répertoires utilisés par postgres (répertoire data, répertoire pg_wal, tablespace etc) que vous avez récupérés, la commande utilisée pour démarrer postgres ainsi que toutes les erreurs apparaissant dans la logs. Si vous avez également des précisions sur le système disque associé à votre serveur vps, notamment si vous avez la garantie qu'un fsync est bien durable et résiste à un crash de l'OS.
De plus, avec le packaging debian la majorité des fichiers de configuration se trouver dans /etc et non /var, avez-vous également récupérés ceux-ci?
Bonjour,
Le service postgres était-il démarré lors de l'accès FTP en "rescue mode" ? Si oui, la copie est inutile et la base est corrompue. Sinon, la copie aurait du fonctionner, pour peu que vous ayez bien sauvegardé toutes les données (répertoire pg_wal s'il était ailleurs, tablespaces ...).
l y avais un problème avec le checksum data (problème que j'ai réussi à régler avec la commande pg_resetwal)
Vous n'avez pas réglé le problème, vous avez définitivement corrompu les données. Si vous avez toujours la copie originale il est possible de voir quel était le problème et peut être le régler, sinon il n'y a pas grand chose à faire.
Il est également possible que soit postgres soit l'OS étaient mal configurés et ne garantissaient pas qu'un fsync écrivait bien les données sur disque de manière durable. Si c'est le cas, il est fort probable que le crash ait définitivement corrompu les données.
Bonjour,
Tout d'abord j'ai déplacé la discussion dans une section qui me semble plus pertinente.
ayant installé ubuntu 22.04 "classique", je me demande si il ne faut pas que j'installe ubuntu server ? ou alors pgsql s'en occupe t'il ?
Postgres ne changera jamais la distribution installée, et un paquet en lui-même ne pourrait pas le faire de toutes façons. Je ne suis pas certain de la différence entre ubuntu et ubuntu serveur, mais il est très probable que la version serveur soit simplement une version un peu plus épurée ne contenant pas de paquet généralement utiles pour un serveur, mais il ne devrait pas y avoir de différence fondamentale. Par exemple pas d'interface graphique, pas de navigateur web etc. Vous pouvez tout à fait supprimer ces paquets manuellement si vous le souhaitez.
Y a t'il un ordre pour organiser chaque install ou je réinstale tout sans m'en préoccuper ?
Je ne comprends pas spécialement la question, mais à priori il n'y a pas d'ordre spécifique. Les paquets ont une gestion des dépendances donc le système s'occupera d'installer ce qui manque en cas de besoin.
Le format directory. Vous pouvez consulter https://docs.postgresql.fr/15/app-pgdump.html pour plus de détails.
Le problème vient très probablement de la mise à jour de glibc (2.24 sur strech et 2.31 sur bullseye). Vous devriez avoir le même comportement au niveau de l'OS avec un simple "sort" en utilisant la même collation.
Bonjour,
À priori soit vous n'avez pas redémarré postgres après avoir changé le port et listen_addresses, soit le service ne démarrage pas et impossible de vous donner la raison sans les logs.
Je suis plutôt du même avis qu'Hervé, partir sur une approche basée sur faire des VACUUM FULL plutôt que corriger la configuration autovacuum ou des tâches planifiées VACUUM me parait une mauvaise idée.
Pour information, le lien que vous postez est pour la version 8.1, j'espère que vous utiliser une version toujours supportée.
La documentation est précise, et spécifie ce qui est conservé et non l'inverse. De la même manière toutes les autres contraintes, indexes, trigger etc ne sont pas récupérés.
car, sauf erreur de ma part, Oracle ou DB2 notamment, le font.
Que se passe-t-il lorsqu'un attribut déclaré NOT NULL est rendu possiblement NULL, type LEFT JOIN etc?
Durant le runtime, j'ai des warnings indiquant que les données lues (select) sont null alors que déclarés not null dans le flux ... bien que le select porte sur des colonnes not null.
Le warning n'est pas très clair. S'agit-il d'un NULL dans les données, ou d'une colonne dans une table déclarée NULL alors que l'ETL indique NOT NULL?
Bonjour,
Le jeu de données retourné ne contient pas d'information sur la nullabilité "globale" d'une colonne. Je ne suis pas certain de ce que vous voulez faire, mais si vous voulez créer une seconde table avec les bonnes contraintes vous pouvez utiliser à la place
CREATE TABLE reponse (LIKE mytable);
INSERT INTO reponse SELECT * FROM mytable;
Bonjour,
Honnêtement une base de données n'est pas faite pour stocker des documents. La meilleure solution est de stocker ces documents dans une arborescence dédiée et ne stocker que certaines métadonnées (typiquement le chemin d'accès vers le fichier en question) en base. Vous aurez de bien meilleures performances en tout point, que ce soit pour l'écriture des fichiers, utilisation de la base de données, sauvegardes etc.
Bonjour,
Ces requêtes permettent d'avoir un transtypage automatique entre les types integer/numeric et text.
Il s'agit d'une extrêmement mauvaise idée. Cela conduira à peu près certainement a des dysfonctionnement divers (requête erronnées qui fonctionnent quand même, très mauvaises performances...).
Y a t'il un autre moyen de répondre à leur problématique sans toucher au schéma pg_catalog ?
Oui, ils peuvent corriger leur applicatif et gérer correctement les types. Il y a une bonne raison pour que ces transtypage n'existent pas par défaut.
Qu'entendez-vous exactement par "un check sur pg_upgrade" ?
Si vous n'avez rien changé pourquoi la moitié des logs à l'air d'être dans un encodage différent ?
Sinon, les logs indique que le serveur a été arrêté explicitement. On dirait cependant que 2 instances étaient démarrées sur le même répertoire de données, est-ce le cas ?
D'après ce que j'ai trouvé la solution est d'utiliser pg_resetlogx
Non, pg_resetxlog / pg_resetwal n'est JAMAIS une solution. Cet outil permet de forcer le démarrage de l'instance malgré des problèmes en forçant une corruption définitive des données.
Pourquoi ne pas mettre en place une rotation des fichiers ou autre ?
Seule la réplication logique vous permettra de faire ça.
Bonjour,
De nos jours gérer 20000 enregistrements ne représente vraiment aucun soucis quelquesoit le moteur de base de données. Vous devriez plutôt choisir un moteur selon les fonctionnalités dont vous avez besoin. Si votre utilisation se limlite à des types classiques (entier, chaine de texte etc), et du SQL vraiment classique, n'importe quel moteur fera l'affaire. Dans votre cas si vous n'avez pas spécialement de compétences sur postgres je vous conseillerais plutôt de partie sur sqlite. La maintenance / sauvegarde est bien plus facile et vous pouvez stocker la base avec votre code.
Utiliser une ancienne version mineure est une très mauvaise idée. Vous pouvez consulter cette page pour plus de détails sur la politique de mise à jour majeure / mineure : https://www.postgresql.org/support/versioning/
À mon avis le plus simple serait de demander directement sur aux auteurs du foreign data wrapper.
Avez-vous effectué un VACUUM ou un ANALYZE ? Je parlais bien d'un ANALYZE (voire VACUUM ANALYZE, mais pas VACUUM seul ni VACUUM FULL).
Pouvez-vous montrer le résultat d'un EXPLAIN (ANALYZE, BUFFERS) sur une requête rapide avec l'ancien derveur et lente avec le nouveau ?
Un VACUUM FULL après un pg_restore n'est pas nécessaire. Je crois cependant qu'un VACUUM FULL ANALYZE ne revient pas au même qu'un VACUUM FULL suivi d'un ANALYZE. Pouvez-vous essayer d'effectuer un ANALYZE sur toutes vos bases et voir si cela corrige le problème ?
Bonjour,
Comment avez-vous fait la migration vers pg15? En cas de pg_upgrade, avez-vous effectué les différentes commandes générées par pg_upgrade, cf https://www.postgresql.org/docs/current/pgupgrade.html étapes 14 et 15 ?
Bonjour,
Si vous parvenez à vous connecter mais qu'une partie des informations semble manquer, le plus probable est que vous vous connectiez sur un mauvais serveur. Etes-vous sur du routage etc et que vous êtes bien sur le même serveur ?
Oui c'est le comportement normal : la séquence n'est pas transactionnelle. Autrement il serait impossible de garantir des valeurs strictement monotones.
Bonjour,
Si vous ne faites que créer une séquence, celle-ci va générer des valeurs en partant de 1. Il vous faut donc assigner la valeur courante en fonction de la valeur maximum de la table en utilisant setval() (voir https://www.postgresql.org/docs/current … uence.html ), idéalement en détenant un verrou exclusif sur la table afin d'éviter des problème en cas d'insertion concurrente.
J'aurais aimé être certain que la séquence 'ma_nouvelle_sequence' ne va pas chercher à créer des valeurs de clé primaire déjà existantes ? Même si d'après ma modeste expérience de base de données, j'imagine que le système va chercher une autre clé primaire en cas de conflit ?... ou bien ça bloque la nouvelle insertion ?
Une séquence ne fait que fournir des entiers strictement croissants, si l'entier fourni existe déjà dans une table vous aurez donc une erreur pour cause de violation de contrainte s'il s'agit d'une clé primaire de la même manière que si vous assigniez la valeur manuellement. Je suis d'ailleurs assez dubitatif sur votre choix d'utiliser une séquence après coup pour un champ existant. À priori l'applicatif fournit lui même une valeur, donc sans modification de tout le code qui peut insérer dans cette table la séquence ne sera jamais utilisée. De plus, si vous ne modifiez qu'une partie du code client il est possible que des valeurs soient insérées manuellement sans passer par la séquence, ce qui mènera a une erreur à la prochaine insertion effecutée avec la séquence utilisée en valeur par défaut.
De la même façon, en utilisant "date_part('year', now())" en expression pour la clause DEFAULT.
Attention toutefois, ce n'est pas exactement le même comportement qu'un trigger: la valeur par défaut, comme son nom l'indique, est uniquement utilisée pour spécifier une valeur si la requête qui insert la ligne n'en spécifie pas, mais ne garantit donc pas que la ligne contiendra l'année en cours si un utilisateur insère une ligne avec explicitement une autre année.
