il y a 3  slots qui sont actifs (standby + un infocentre + la souscription vers GCP initiale)   + 7 slots de synchro inactifs 

Voici la commande de creation de souscription
CREATE SUBSCRIPTION gcp_scapnorbi  CONNECTION 'host=10.72.0.115 port=60000  user=datastream  password=********* dbname=scapnor' publication scapnor_gcp_bigquery;

Quand je regarde les logs GCP la souscription essaye de lancer 329 tables différentes (started ) sur les 333 comme si le paramètre max_sync_workers_per_subscription  n'etait pas pris en compte alors qu'il est à 2 sur GCP  . Aucun statut 'finished' dans les logs GCP, aucune table n'est répliquée et le process de réplication tourne à l'infini avec ces messages started depuis l'abonné et le message 'increase max_replication_slot' depusi le publieur . Si je detruit les slots inactif il en regénère d'autres dans la foulée qui sont inactifs.

Sur l'abonné.
scapnorbi=> show max_sync_workers_per_subscription ;
max_sync_workers_per_subscription
-----------------------------------
2
(1 row)

Si je change de publieur avec la même version pg je n'ai pas ce problème .

A part agrandir le max_replication slots (et de combien ?) que puis-je faire pour que la réplication démarre ?
merci

psql -U postgres
psql: erreur : la connexion au serveur sur le socket « /var/run/postgresql/.s.PGSQL.5432 » a échoué : FATAL:  le système de bases de données se lance

~$ systemctl status postgresql
● postgresql.service - PostgreSQL RDBMS
     Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; preset: enabled)
     Active: active (exited) since Tue 2025-02-18 15:10:06 CET; 8 months 2 days ago
   Main PID: 1366524 (code=exited, status=0/SUCCESS)
        CPU: 1ms

pg_lsclusters
Ver Cluster Port Status          Owner    Data directory              Log file
15  main    5432 online,recovery postgres /var/lib/postgresql/15/main /var/log/postgresql/postgresql-15-main.log

Existe t'il un moyen de régler le problème ?

Dans mon application Java je fais des INSERT en batch avec :

preparedStatement.addBatch();

et tous les XXX je fais :

preparedStatement.executeBatch();

J'utilise le JDBC Driver 42.7.5 en production, pas de soucis mais à partir de la version 42.7.7 (je n'ai pas testé la version 42.7.6 parce que noté avec une vulnérabilité sur Maven!?)

J'ai fais le test plusieurs fois avec des données différentes...

La vitesse passe de +- 5500/sec (42.7.5) à +- 200/sec (42.7.7 ou plus)

N'ayant rien changé à mon code Java cela vient à coup sûr du JDBC Driver

Une idée ?

Merci d'avance.

J'essaye de comprendre comment identifier les fichiers temporaires dans un plan d'execution (avec les options ANALYZE BUFFERS).
Autrement dit, faire le raccord avec ce que je vois dans un rapport pgBadger.

Outre les "Disk" assez explicites, je pense me pencher vers l'information "written" comme dans cet exemple :

Buffers: shared hit=364604, temp read=91606 written=97586

Et là, j'ai un doute.
Est-ce que la ligne Buffers est propre à son nœud ou représente aussi ses sous-nœuds ?

Autrement dit, si j'essaye d'optimiser la même requête SQL et que je passe de :

Buffers: shared hit=913220, temp read=102462 written=109406
Buffers: shared hit=913220, temp read=102462 written=109406
Buffers: shared hit=913220, temp read=101442 written=108383
Buffers: shared hit=913220, temp read=101442 written=108383
Buffers: shared hit=913220, temp read=101442 written=108383
Buffers: shared hit=913220, temp read=101442 written=108383
Buffers: shared hit=913190, temp read=100422 written=107360
Buffers: shared hit=734312, temp read=8877 written=9232
Buffers: shared hit=723711, temp read=8877 written=9232
Buffers: shared hit=643019, temp read=8877 written=9232
Buffers: shared hit=562327, temp read=8877 written=9232
Buffers: shared hit=496048, temp read=8877 written=9232
Buffers: shared hit=26335, temp written=8120
Buffers: shared hit=178856, temp written=91984

à ça :

Buffers: shared hit=640678, temp read=93883 written=100434
Buffers: shared hit=640678, temp read=92863 written=99411
Buffers: shared hit=640678, temp read=92863 written=99411
Buffers: shared hit=640678, temp read=92863 written=99411
Buffers: shared hit=640678, temp read=92863 written=99411
Buffers: shared hit=640648, temp read=91843 written=98388
Buffers: shared hit=178856, temp written=93000

Est-ce que j'ai réduit les écritures de :
- 109406-100434=8972 blocs
ou de :
- 905968-689466=216502 blocs

J'ai compris qu'un champs NUMERIC ne peux pas avoir de valeur nulle.
Quelle est donc la bonne pratique pour définir un tel champs lorsque sa
valeur sera connue après l'insertion d'un tuple?

Voici un exemple fictif basé sur le coût de sortie de stock d'un
produit.

Lorsque les carottes sortent du stock on connaît leur prix de vente mais
on ne connais pas encore le coût du dédouanement pourtant celui-ci est
un élément des charges.

La solution que j'image c'est de mettre la colonne "taxe_douane" dans
une table séparée. Dans ce cas seules les valeurs douanières déjà
connues y seront présentes. Dans cette table séparée, je n'aurai donc
que des tuples contenant des valeurs déjà connues.

Est-ce la bonne pratique ou est-ce qu'il y a une pratique mieux adaptée
pour définir un champs NUMERIC dont on ne connaît pas encore la valeur
mais dont on est sûr que plus tard il sera différent de 0?

Je vous remercie par avance.

Pour des raisons techniques, nous sommes contraints de suspendre les inscriptions à ce forum jusqu'à nouvel ordre.

* Si disposez déjà d'un compte sur le forum, cela ne change rien pour vous. Vous pouvez continuer à poster des messages sur le forum
* Si vous ne disposez pas d'un compte sur le forum, vous ne pouvez pas en créer un pour l'instant.

Nous sommes conscients que cette décision se fait au détriment des nouveaux usagers potentiels et nous nous en excusons.

Nous travaillons à rétablir le service le plus tot possible. Néanmoins l'équipe d'administration du site est composée de personnes bénévoles dont le temps est limitée. Nous ne pouvons pas nous engager sur une date de rétablissement.

Nous sommes bien sur ouverts à toute discussion et toute proposition à ce sujet. Vous pouvez nous joindre à l'adresse contact@postgresql.fr

Merci de votre compréhension.

Damien CLOCHARD pour les administrateurs de la plateforme postgresql.fr

Merci d'avance à ceux qui voudrait bien répondre

Cordialement,

Ce mois-ci, il vous parle de la nouvelle option pour la commande EXPLAIN, proposée par Robert Haas :

PostgreSQL 18 - Modules optionnels pour EXPLAIN

Nous vous proposons aujourd’hui une présentation de cette fonctionnalité. Nous illustrerons notre article avec un plugin expérimental que nous avons développé. Ce plugin permet d’archiver les WALs et sauvegarder une instance vers un bucket S3 avec pgBackRest. »

La suite ici : Plongez dans le monde de CloudNativePG #6 - Plugin pour CloudNativePG

Depuis janvier 2025, Pierrick et Julian vous proposent une série d'articles dédié à l'opérateur CloudNativePG.

Depuis janvier 2025, Pierrick, DBA consultant chez Dalibo, vous propose une série d'articles dédié à l'opérateur CloudNativePG.

Je souhaite installer postGreSQL16 sur RockyLinux avec ansible.
J'ai déjà commencé le playbook, tout s'installe plutôt bien mais je me heurte à des questions de configuration, les voici:

- Lorsque je fais l'init DB ( /usr/pgsql-16/bin/postgresql-16-setup initdb ), faut il le faire en root ou avec le compte postgres  ?

- quelles sont les best practices pour les BDD, faut - il les déplacer le répertoire "Base" sur un volume disque dédié, idem pour le répertoire pg_wal  ?

merci pour votre aide

J'ai pas mal cherché, sans rien trouver, mais je suis loin de bien connaître Postgresql. J'ai tout de même revu de près la config de Postgresql en m'inspirant des articles et doc de Dalibo.

Le VPS est un 8 coeurs avec 8 Go de Ram, et un disque classique, non SSD. Il est utilisé depuis 5 ans. Le dossier Postgresql fait environ 1 GB. En ce moment, la charge varie de 0,10 à 0,20 et l'utilisation de l'appli Odoo est très faible, parfois un seul utilisateur qui ne fait que lire. Pourtant , non seulement c'est très lent mais certaines requêtes habituelles de l'appli Odoo échouent (pour donner une idée, il y a 7 ans ça tournait correctement sur un VPS double-coeur avec 2 GB de Ram, avec sensiblement le même contenu en base de données).

Comme il fait encore froid, j'aimerai comprendre sans arracher le peu de cheveux qui me reste. Pistes et idées sont les bienvenues.

Je rencontre un problème de démarrage avec PostgreSQL 12 sur Ubuntu 20.04 après un arrêt brusque de mon serveur suite à une panne électrique. Après une vérification du système de fichiers (fsck) qui n'a révélé aucune erreur, PostgreSQL refuse de démarrer.

Voici les principales informations :

Version PostgreSQL : 12.22 (Ubuntu 12.22-2.pgdg20.04+1)
Système d'exploitation : Ubuntu 20.04
Erreur : PANIC: le checkpoint de réplication a le mauvais nombre magique (139744468>)
Contexte : Aucune réplication de base de données n'est configurée. Le répertoire pg_replslot est vide.
Tentatives : Vérification du système de fichiers, vérification des permissions, vérification de l'espace disque, tentative de redémarrage.
multipathd des erreurs sont aussi visible dans les logs.
Je suis à la recherche de pistes pour résoudre ce problème. Les journaux de PostgreSQL ne fournissent pas d'informations supplémentaires. J'ai vérifié les fichiers de configuration, les permissions et l'espace disque, mais le problème persiste.

Auriez-vous des suggestions ou des pistes à explorer ?

Merci d'avance pour votre aide.

Je rencontre un problème de démarrage avec PostgreSQL 12 sur Ubuntu 20.04 après un arrêt brusque de mon serveur suite à une panne électrique. Après une vérification du système de fichiers (fsck) qui n'a révélé aucune erreur, PostgreSQL refuse de démarrer.

Voici les principales informations :

Version PostgreSQL : 12.22 (Ubuntu 12.22-2.pgdg20.04+1)
Système d'exploitation : Ubuntu 20.04
Erreur : PANIC: le checkpoint de réplication a le mauvais nombre magique (139744468>)
Contexte : Aucune réplication de base de données n'est configurée. Le répertoire pg_replslot est vide.
Tentatives : Vérification du système de fichiers, vérification des permissions, vérification de l'espace disque, tentative de redémarrage.
multipathd des erreurs sont aussi visible dans les logs.
Je suis à la recherche de pistes pour résoudre ce problème. Les journaux de PostgreSQL ne fournissent pas d'informations supplémentaires. J'ai vérifié les fichiers de configuration, les permissions et l'espace disque, mais le problème persiste.

Auriez-vous des suggestions ou des pistes à explorer ?

Merci d'avance pour votre aide.