Vous n'êtes pas identifié(e).
Pages : 1
j'ai trouvé avec la fin du log d'hier :
Après la création de la table sur le secondaire et la commande
ALTER SUBSCRIPTION, j'ai omis d'attribuer les droits de SELECT au rôle crée pour la réplication.
Une fois GRANT SELECT ON TABLE f132800_ensemble to replicant, la table sur le secondair s'est correctement remplie.
Merci pour l'attention.
J'utilise pgAdmin4 pour tester l'ajout et la suppression de de données.
La publication sur le serveur primaire :
CREATE PUBLICATION f132880_publication
FOR ALL TABLES
WITH (publish = 'insert, update, delete, truncate', publish_via_partition_root = false);La souscription sur le serveur secondaire :
CREATE SUBSCRIPTION subscription_f132880
CONNECTION 'host=xxx user port=5432 user=xxx dbname=F132880'
PUBLICATION f132880_publication
WITH (connect = true, enabled = true, create_slot = false, slot_name = subscription_f132880, synchronous_commit = 'off');Jusque là tout fonctionne.
Définition de la table créée ultérieurement sur le primaire et recréée sur le secondaire :
CREATE TABLE IF NOT EXISTS public.f132880_ensemble
(
ogc_fid integer NOT NULL DEFAULT nextval('f132880_ensemble_ogc_fid_seq'::regclass),
id character varying(254) COLLATE pg_catalog."default",
x numeric(24,15),
y numeric(24,15),
z numeric(24,15),
code character varying(254) COLLATE pg_catalog."default",
geometrie character varying(254) COLLATE pg_catalog."default",
type character varying(254) COLLATE pg_catalog."default",
interpret character varying(254) COLLATE pg_catalog."default",
numens numeric(10,0),
date date,
geom geometry(MultiPolygon,2154),
CONSTRAINT f32880_ensemble_pkey PRIMARY KEY (ogc_fid1)La séquence pour la clef primaire :
CREATE SEQUENCE public.f132880_ensemble_ogc_fid_seq
INCREMENT 1
START 1
MINVALUE 1
MAXVALUE 2147483647
CACHE 1;
ALTER SEQUENCE public.f132880_ensemble_ogc_fid_seq
OWNER TO blois;Les modifications sur les tables initiales fonctionnaient toujours mais la table secondaire f132880_ensemble était vide.
Effectivement, je n'avais pas exécuté de
ALTER SUBSCRIPTIONDonc j'ai rectifié le tir sur le serveur secondaire:
alter subscription subscription_f132880 REFRESH publication ;Même après cela, la table sur le secondaire reste vide mais tout fonctionne toujours pour les autres.
JE ne vois rien de particulier dans les logs du secondaire, mais j'y retourne ce matin plus avant.
les deux tables ont exactement la même définition : j'ai repris le script de la première pour créer la seconde ainsi que la sequence.
Notamment, êtes-vous sûr d'avoir créé la nouvelle table dans la base publiée ?
absolument : j'ai les deux sous les yeux dans pgadmin4. J'ai même rempli la seconde table avec les données de la première en me disant qu'il fallait peut-être initier le truc (j'y croyais pas vraiment).
Je pense qu'il faudrait un exemple complet
un exemple de ? sous quelle forme ?
Bonjour,
Dans le cadre d'une réplication logique, j'ai fait un dump d'une base sans les donnéesd 'un serveur primaire (-s) et restauré la sauvegarde sur un serveur secondaire.
Puis j'ai configuré le primaire ainsi :
wal_level = logical # minimal, replica, or logical
# (change requires restart)
#fsync = on # flush data to disk for crash safety
# (turning this off can cause
# unrecoverable data corruption)
#synchronous_commit = on # synchronization level;
# off, local, remote_write, remote_apply, or on
...
#synchronous_standby_names = ''J'ai crée la publication :
CREATE PUBLICATION f132880_publication
FOR ALL TABLES
WITH (publish = 'insert, update, delete, truncate', publish_via_partition_root = false);Puis créé la souscription sur le serveur distant :
CREATE SUBSCRIPTION subscription_f132880
CONNECTION 'host=xxx user port=5432 user=xxx dbname=F132880'
PUBLICATION f132880_publication
WITH (connect = true, enabled = true, create_slot = false, slot_name = subscription_f132880, synchronous_commit = 'off');A la suite de quoi, les données ont bien été copiées sur le serveur secondaire depuis le primaire, et les commandes DDL sur ce dernier reproduites sur le secondaire.
Par la suite, une nouvelle table a été créée sur le primaire. Conformément à la doc, j'ai créé la même table sur le serveur secondaire, les commandes DML étant ignorées
Mais :
* la nouvelle table ne s'est pas rempli automatiquement des valeurs de la table présente sur le primaire.
* tout ajout dans la nouvelle table primaire ne s'ajoute pas à la table identique secondaire.
A l'évidence quelque chose m'a échappé, mais je ne trouve pas quoi.
Merci d'avance pour votre aide 
Bonjour,
Droits d'accès identiques.
J'ignore ce qu'est un CRC mais je me renseigne
Merci
Pour être complet : j'ai procédé à la mise à jour sur un serveur de test avant de faire celle sur le serveur de prod.
Les deux serveurs sont sous le même windows server, avec le même Postgres.
La mise à jour sur le server test s'est faite sans anicroche contrairement au serveur de prod.
A propos du service réseau, la DSI m'a répondu que dans les deux config, c'était le service par défaut qui était utilisé.
Aucun anti-virus d'installé sur les serveurs et ca va être corrigé 
Sinon, je tenterai bien de remplacer les fichiers du serveur de prod par ceux mis à jour sur le test. Et de tout relancer.
(Après, c'est la reinstall d'un PostgreSQL propre avec le PostGIS qui va bien, je ne sais pas faire mieux)
dans le fichier de log, je trouve :
2022-01-11 13:40:27.314 CET [3224] 11 db=blois,user=POSTGIS ERROR: 58P01: could not load library "C:/Program Files/PostgreSQL/13/lib/postgis-3.2.dll": unknown error 127
2022-01-11 13:40:27.314 CET [3224] 12 db=blois,user=POSTGIS LOCATION: internal_load_library, d:\pginstaller_13.auto\postgres.windows-x64\src\backend\utils\fmgr\dfmgr.c:248
2022-01-11 13:40:27.314 CET [3224] 13 db=blois,user=POSTGIS STATEMENT: begin;
alter extension POSTGIS
update to "3.2.0"rien de plus.
Et le postgis-3.2dll est bien présent dans le répertoire.
Bonjour,
J'essaie de mettre à jour PostGIS de 3.1 à 3.2 sous PostgreSQL 13 WIndows server R8.
En utilisant stackbuilder, j'ai téléchargé le bundle PostGIS 3.2.
Pendant l'installation, j'ai eu des erreurs "could not open for writing" de certains fichiers dll (libcurl-4.dll par exemple).
J'ai lu sur stackexchange notamment que je pouvais ignorer ce message...
A la fin de l'installation de Postgis, je me connecte à une base de données et j'exécute
Begin ;
alter extension POSTGIS
update to "3.2.0 J'ai eu une erreur : impossible de charger la bibliothèque
"C:/Program Files/PostgreSQL/13/lib/postgis-3.2.dll" : erreur inconnue 127
A partir de là, y a-t-il un moyen de charger la bibliothèque correctement ? Ou si je dois recommencer depuis le début, comment puis-je éviter les erreurs de dll ?
Merci
Comme annoncé, je reviens pour un retour d’expérience.
La vérification testée sur un petit jeu de données fonctionne.
Plus qu'à passer en production.
Merci.
Par contre j'ai un doute sur l'exemple AL_l
Tout à fait, c'est corrigé.
Merci pour le "?", c'est ce que j'étais en train de chercher dans la doc.
Je teste et reviendrai conclure (j'espère).
@jmarsac : énumérer toutes les valeurs possibles revient à en écrire plus de 1000 ! Et en terme de maintenance c'est fastidieux, regenerer la liste des 1000 si des occurrences de la liste changent...
utiliser les expressions regulières ? je vais regarder cela.
@dverite : voilà la liste des caractères autorisés
'A', 'AL', 'AS','B','C','D', 'G', 'L', 'LA', 'LS','NO', 'R', 'S', 'SA', 'SL','T', 'TL', 'TS', 'X', 'd', 'h', 'l', 'm', 'p', 'r', 't', '_lab', '_g', '_o', '_p', '_tc', '_v', '_x'Et donc les valeurs autorisées ne peuvent être qu'une combinaison d'une des 19 premières (les majuscules) avec/ou pas d'une des 7 suivantes avec/ou pas d'une des 7 dernières.
Ce qui donne comme valeurs finales que je souhaite autoriser par exemple : Ad_g ou ALl.
I.e. il faut empêcher que les utilisateurs puissent rentrer d'autres lettres.
J’espère que c'est plus clair.
Merci
Disons que la liste comporte trois grands ensembles de caractères : les majuscules, les minuscules et des occurrences avec un _ devant.
Potentiellement, les utilisateurs saisiront au minimum un caractère du premier groupe et au maximum un de chaque groupe - concaténés donc. (normalement car le débat sur le du nombre de caractères n'est pas tout à fait clos).
Je corrige le message initial pour éviter cette confusion.
PostgreSQL 11.5, W10 server 2012.
Bonjour,
Je souhaite restreindre les valeurs d'un champ à une combinaison de caractères.
Voici un extrait de la liste :
'A', 'AL', 'SL', 'd', 'h', '_g', '_v')Et donc je souhaite autoriser des valeurs uniquement issues de la combinaison des éléments de cette liste à travers une contrainte CHECK.
Mais comme la liste comporte une petite trentaine de caractères autorisés, je préfère éviter de lister les "ouatmilles" combinaisons possibles du genre
...CHECK (monchamp IN ('A', 'AL_v ','SL_g', 'Ah,...)Auriez-vous quelques pistes sur ce sujet ?
Merci
vous devez utiliser la méthode MD5 dans votre pg_hba.confle changement de méthode en md5 a permis de me connecter après la restauration des globales (et même pas besoin de sans recharger la config même).
Merci
du changement à venir également coté method j'imagine ?
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all scram-sha-256
# IPv4 local connections:
host all all 127.0.0.1/32 scram-sha-256
# IPv6 local connections:
host all all ::1/128 scram-sha-256
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all scram-sha-256
host replication all 127.0.0.1/32 scram-sha-256
host replication all ::1/128 scram-sha-256le message d'erreur est
psql: erreur : FATAL : authentification par mot de passe échouée pour l'utilisateur postgres
Et ce après la restauration des globales.
la valeur du paramètre password_encryption des deux serveurs soit différente
sur le 11 : md5
sur le 13 : scram-sha-256
J'ai benoitement, changer cette dernière en md5, relancé le service postgres13 et tenter la connexion : échec psql comme pgadmin. Je cherche donc dans cette direction.
Merci
Désolé.
J'ai complété le message intial avec le système d'exploitation Windows : Server 2012.
il manque le h entre - et localhost
juste une faute de frappe, c'est corrigé dans le message initial itou.
Je vais tâcher de retrouver le message d'erreur qui stipulait la nécessité d'un mot de passe. Car j'ai dû passer à autre chose entre -temps, mais je vais y revenir.
Merci
Bonjour,
Je pensais maitriser un tant soit peu la restauration d'une bdd d'une instance vers une autre et je me trompais. (C'est dingue on a beau écrire des protocoles bien documentés qui fonctionnent lorsqu'on les écrit, et ben non toujours un truc qui m...e);
Bref...
J'ai sauvegardé les globales à plat et une base de données (pg_dump) du serveur sous PostgreSQL11 (méthode Dalibo).
J'ai installé un serveur PostgreSQL 13 avec l'installateur Entreprisedb.
Les deux instances sont sous windows server 2012.
Après une première installation laborieuse de la nouvelle instance avec un souci de mot de passe pour l'utilisateur postgres (pas compris pourquoi mais c'est reglé après une reinstallation), tout est rentré dans l'ordre avec une connexion via pgadmin4 utilisant l'utilisateur postgres.
Je restaure les globales sauvegardées avec
psql -h localhost -p 5413 -U postgres -f c:\...la restauration se passe sans message d'erreur.
Depuis, plus possible de se connecter depuis pgadmin4 : problème de mot de passe avec postgres. Qu'à cela ne tienne, j'essaie d'utiliser un compte restauré : impossible problème de mot de passe également.
- J'ose espérer que la sauvegarde et la restauration ds globales se fait avec les mots de passe ??? D'ailleurs je ne vois pas pourquoi postgres ne fonctionne plus alors que j'ai vérifié le mot de passe sur le serveur initial qui est le même sur la nouvelle instance.
Plus étrange, je peux me connecter en psql à avec postgres après restauration des globales. En revanche, si j'essaie de me connecter avec un autre utilisateur
psql - h localhost -U autre erreur =
"database "autre" n'existe pas
Plait-il ? -U c'est pour USER monsieur psql...
J'ai bien un dumpall de l'instance, complète donc, mais je souhaite éviter cela pour le moment.
Avez-vous quelques remarques, conseils ou expériences qui me permettraient de comprendre et résoudre ?
Merci,
Cette semaine est un cauchemar.
Par le passé, j'avais déjà essayé pg_upgrade sans succès.
Re echec cette fois.
Je ne tergiverse plus : je vais définitivement utiliser pg_dumpall via pgadmin3. Ca a bien fonctionné hier sur le serveur de test.
Quant à la 10.3, je vais regarder de plus près.
Merci
bonjour,
Sur un windows server 2008, j'ai une instance de Postgres 9.3. J'ai installé à coté une version 9.6.8 x64 à partir du package entreprisedb.
Postgis a été installé sur les deux serveurs.
Le but est de migrer les bdd de 9.3 à 9.6.
J'ai arrété les deux services 9.3 et 9.6 avant de tester pg_upgrade avec l'option -check.
Devant le message classique - aux solutions diverses et variées -
connection to database failed: could not connect to server: Connection refused (0x0000274D/10061)
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 50432?
could not connect to server: Connection refused (0x0000274D/10061)
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 50432?
et l'observateur d’événements de Windows peu loquace
dépassement du délai pour le démarrage du serveur
,
je me suis penché sur le problème de connexion à l'ancien serveur pour commencer : j'ai donc utiliser pg_ctl pour tenter de comprendre le problème de connexion sans succès :
command: "C:\Program Files (x86)\PostgreSQL\9.3\bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "C:\Program Files (x86)\PostgreSQL\9.3\data" -o "-p 50432 -b " start >> "pg_upgrade_server_start.log" 2>&1
en attente du démarrage du serveur.... attente arrêtée
pg_ctl : n'a pas pu démarrer le serveur
Galérant depuis plusieurs jours sur ces questions, je voulais tenter la restauration d'un pg_dumpall de l'ancien serveur dans le nouveau.
Le problème maintenant est que je ne peux plus démarrer aucun service Postgres via services.msc :
Le service postgresql-9.3 sur ordinateur local a démarré et s'est ensuite arrêté...
A part désinstaller (encore) postgres 9.6 pour refaire l'install afin de directement tenter le psql de restauration, je n'ai pas trouvé de solution pour redémarrer les services et encore moins les raisons pour lesquelles je n'arrive pas à démarrer les serveurs.
Auriez-vous qques pistes concernant le démarrage des services ? (le pg_upgrade, j'abandonne pour le moment)
Merci
remarque : je suis logé en tant qu'administrateur.
remarque 2 : rebooter le serveur ne relance pas non plus les services postgres
Remarque 3 : quand j'ai installé les deux versions de postgres, je réussissais à arrêter et démarrer les services. Depuis que j'ai commencé à utiliser pg_upgrade, impossible. J'ignore s'il y a un lien de cause à conséquence.
remarque 4 : je viens de desinstaller 9.6.8, rebooté et la 9.3 ne démarre quand même pas...misère...
Pages : 1