Forums PostgreSQL.fr

Bonjour,

j'ai un master sous centos 7, postgresql 15.7. (x86_64)
J'ai un slave sous red hat 9, postgresql 15.8. (x86_64)

J'ai un warning sur le slave:

[postgres@PR-DRS-DBC-01 log]$ psql
WARNING:  database "postgres" has a collation version mismatch
DETAIL:  The database was created using collation version 2.17, but the operating system provides version 2.34.
HINT:  Rebuild all objects in this database that use the default collation and run ALTER DATABASE postgres REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.
psql (15.8)
Type "help" for help.

C'est grâve docteur?

Apparemment il faudrait logiquement changer la collation du master, mais je ne suis pas sur que je peux encore updater centos 7. Du nouveau matos est prévu ... pour l'an prochain.
Par contre, autre idée, est-il possible d'avoir la liste des tables qui n'utilisent PAS la collation par défaut et de la forcer (je crains le downtime).
Et si je ne fais rien sur le master, et que je lance la procédure sur le slave en cas de désastre, quel sera le downtime?

Merci.

Bonjour,
j'ai une vm avec un pg 15, une db de 2Tb, 24Gb RAM, 8 coeurs (16 threads).
j'ai mis

max_connections=150
shared_buffers = 7144MB
effective_cache_size = 11200MB
maintenance_work_mem = 1536MB
work_mem=22MB

Quand je lance postgrestuner j'ai ce message

[WARN]    The sum of max_memory and effective_cache_size is too high, the planner may create bad plans because the system buffercache will probably be smaller than expected, especially if the machine is NOT dedicated to PostgreSQL.

par contre is cache_size-4Gb<buffer_size, j'ai aussi une erreur.
Devrais-je réduire les deux ou jouer avec un autre paramètre?

Merci.

Bonjour,

J'ai un serveur red hat 9 avec postgres 13.
Le but est d'upgrader vers postgres 15 (in-place upgrade), donc je dois avoir les deux versions sur le serveur.

Lors de l'installation de postgres 15, j'ai ces messages:

failed to link /usr/bin/psql -> /etc/alternatives/pgsql-psql: /usr/bin/psql exists and it is not a symlink
failed to link /usr/bin/clusterdb -> /etc/alternatives/pgsql-clusterdb: /usr/bin/clusterdb exists and it is not a symlink
failed to link /usr/bin/createdb -> /etc/alternatives/pgsql-createdb: /usr/bin/createdb exists and it is not a symlink
failed to link /usr/bin/createuser -> /etc/alternatives/pgsql-createuser: /usr/bin/createuser exists and it is not a symlink
failed to link /usr/bin/dropdb -> /etc/alternatives/pgsql-dropdb: /usr/bin/dropdb exists and it is not a symlink
failed to link /usr/bin/dropuser -> /etc/alternatives/pgsql-dropuser: /usr/bin/dropuser exists and it is not a symlink
failed to link /usr/bin/pg_basebackup -> /etc/alternatives/pgsql-pg_basebackup: /usr/bin/pg_basebackup exists and it is not a symlink
failed to link /usr/bin/pg_dump -> /etc/alternatives/pgsql-pg_dump: /usr/bin/pg_dump exists and it is not a symlink
failed to link /usr/bin/pg_dumpall -> /etc/alternatives/pgsql-pg_dumpall: /usr/bin/pg_dumpall exists and it is not a symlink
failed to link /usr/bin/pg_restore -> /etc/alternatives/pgsql-pg_restore: /usr/bin/pg_restore exists and it is not a symlink
failed to link /usr/bin/reindexdb -> /etc/alternatives/pgsql-reindexdb: /usr/bin/reindexdb exists and it is not a symlink
failed to link /usr/bin/vacuumdb -> /etc/alternatives/pgsql-vacuumdb: /usr/bin/vacuumdb exists and it is not a symlink

Après l'upgrade, psql ne fonctionne plus, je dois ajouter le dossier des binaires pgsql au path.
Y a-t'il un script qui pourrait recréer tous les liens dans /usr/bin?

Merci.

Bonjour,

j'ai une db volumineuse (5Tb). Les sysadmins voudraient tout passer en docker.
Le souci est que si je veux faire un in-place upgrade (car la db est grosse), je dois spécifier les anciens binaires:https://www.postgresql.org/docs/16/pgupgrade.html .

Est-il possible de créer un même docker qui contienne deux versions différentes de postgres?

Merci.

Bonjour,

J'ai mis en place une réplication (hot standby, réplication physique, pas logique) entre deux bâtiments distincts.

* est-il possible de faire en sorte que le primaire stoppe si le standby est déconnecté?
* la solution "préconisée" pour faire un switchover est de couper le primaire puis faire un "promote" sur le standby. En coupant le primaire, ne risque-t'on pas d'arrêter la réplication en cours et donc de créer un gap entre le primaire et le standby?
* Y a-t'il un script à tourner sur le primaire , au cas où ils ne serait plus connecté, de mettre quelque part les wal non reçus par le standby (wals qui seraient envoyés manuellement)?
* quand on coupe le primaire, s'assure-t'il de transmettre jusqu'au dernier wal vers le standby avant de s'arrêter?

Le but étant de diminuer le risque de perte de données en cas de basculement contrôlé.

Merci des réponses et conseils.

Bonjour,

je voudrais exporter une table nommée "bievent' (d'un vieux postgres 9.2) pour l'importer dans une db de test.
Mon user n'a accès qu'en lecture mais pas en écriture (production).

PGPASSWORD=<mon passwd> pg_dump -f /tmp/lz.dmp -O -t bievent -h 127.0.0.1 -p 5433 -U <monuser> <database>

Mais j'obtiens

pg_dump: [archiver (db)] query failed: ERROR:  permission denied for relation bievent_id_seq
pg_dump: [archiver (db)] query was: SELECT sequence_name, start_value, increment_by, CASE WHEN increment_by > 0 AND max_value = 9223372036854775807 THEN NULL      WHEN increment_by < 0 AND max_value = -1 THEN NULL      ELSE max_value END AS max_value, CASE WHEN increment_by > 0 AND min_value = 1 THEN NULL      WHEN increment_by < 0 AND min_value = -9223372036854775807 THEN NULL      ELSE min_value END AS min_value, cache_value, is_cycled FROM bievent_id_seq

Bref, il ne peut pas lire la séquence bievent_id_seq (qui donne l'id de la table) , refuse de faire un dump, mais ce n'est pas la séquence que je veux exporter mais bien la table.
J'ai essayé sans succès:
* d'ajouter -a
* d'ajouter --inserts
* d'ajouter -T  bievent_id_seq

Comment puis-je faire pour n'exporter QUE la table?

Merci.

Bonjour,

J'ai mis en place un standby entre deux postgres 13 (centos 7) en utilisant la même confiig qui fonctionnait parfaitement entre deux postgres 10, à savoir:
* sur le master:

listen_addresses = '*'
archive_command = 'test ! -f /var/lib/pgsql/13/wal/%f && cp %p /var/lib/pgsql/13/wal/%f'
archive_mode=on

+ 1 ligne dans pg_hba.conf

* sur le slave:

listen_addresses = '*'
port=5433
primary_conninfo = 'host=127.0.0.1 user=postgres'
hot_standby = on
restore_command = 'cp /var/lib/pgsql/13/wal/%f %p'
archive_cleanup_command = '/usr/pgsql-13/bin/pg_archivecleanup /var/lib/pgsql/13/wal %r'

Mais ca ne marche plus: le slave ne se connecte pas au master, ne copie pas les mises à jour (j'ai généré 1Gb d'updates) et ne donne pas d'erreur:

Régression? Ou est-on maintenant obligé d'utiliser les "replication slots"? J'ai essayé de créer un "replication user", sans changement.

Merci.