Vous n'êtes pas identifié(e).
Le compte d'administration créé par défaut est postgres et non postgresql.
Vous avez peut-être créé un compte postgresql pour lequel il faut donner le mot de passe d'après pg_hba.conf ?
Exemple avec la version 16.1 sur Linux (ça doit être la même chose sur Windows):
$ psql -U postgres
psql (16.1)
Type "help" for help.
postgres=# \du
List of roles
Role name | Attributes
-----------+------------------------------------------------------------
postgres | Superuser, Create role, Create DB, Replication, Bypass RLSD'après la discussion https://www.postgresql.org/message-id/1 … .pgh.pa.us, il s'agit d'une limite connue des index BRIIN.
Peut-être qu'il s'agit plus d'une limite du "query planner" ?
Non ce n'est pas possible même avec une autre vue d'après https://postgrespro.com/list/thread-id/2580844.
Bonjour,
Aujourd'hui je vois aussi:
Cette page n'existe plus
Vous avez suivi un lien vers une page qui n'existe plus. Vous pouvez afficher la liste des anciennes revisions pour voir quand et pourquoi la page a été supprimée, pour accéder à ses anciennes révisions ou pour la restaurer.
Et l'historique de la page en question dit que la page a été supprimée le 29 juillet:
Anciennes révisions
Voici les anciennes révisions de la page en cours. Pour les comparer, sélectionnez-les avec les cases à options. Pour revenir à une ancienne révision, affichez-la en cliquant sur son nom, puis cliquez sur le bouton « Modifier cette page » et enregistrez-la.
2022/07/29 10:58 accueil – supprimée aquaslotgacor -2.6 KB (Version actuelle)
2022/07/25 06:44 Différences avec la version actuelle accueil – ancienne révision (2022/06/17 11:04) restaurée anthonyn +2.1 KB
J'ai restauré la version du 25.07.
En général on optimise une requête lorsque quelqu'un remonte un problème de performance dont l'analyse désigne la requête en question comme étant trop lente.
Pour aller plus loin:
Guide de formation Dalibo PG Performances
En attendant vous pouvez essayer d'utiliser mon extension pg_timeout https://github.com/pierreforstmann/pg_timeout.
Oui, c'est une bonne pratique de séparer les exécutables PostgreSQL et les données PostgreSQL (PGDATA). Et ce serait encore mieux de séparer les journaux de transaction (dossier pg_wal dans PGDATA) des autres données si possible.
Il y a des règles de nommage par défaut utilisées par les programmes d'installation pour PGDATA:
/var/lib/pgsql/datasous Linux par exemple mais ces règles doivent être adaptées si vous avez plusieurs plusieurs instances sur la même machine.
1. La différence entre cert et md5: cert va utiliser le certificat - qui doit être stocké côté client - pour ne pas demande de mot de passe alors que md5 va demander et vérifier le mot de passe enregistré dans la base.
2. Je ne sais pas.
Dans pg_hba.conf vous pouvez ajouter la méthode CERT:
hostssl db usr 192.168.0.1/16 cert Demander à PostgreSQL de prendre en compte cette modification avec:
pg_ctl reloadEt vérifier dans le log de PostgreSQL qu'il n'y a pas d'erreur (car s'il y a une erreur dans pg_hba.conf, pg_ctl ne dit rien):
2020-06-29 09:00:20.313 CEST [11349] LOG: received SIGHUP, reloading configuration filesS'il y a une erreur vous avez des messages qui signifient que le modification de pg_hba.conf n'a pas été prise en compte:
2020-06-29 09:03:31.821 CEST [11349] LOG: received SIGHUP, reloading configuration files
2020-06-29 09:03:31.822 CEST [11349] LOG: invalid authentication method "clientcert=verify-ca"
2020-06-29 09:03:31.822 CEST [11349] CONTEXT: line 83 of configuration file "/var/lib/pgsql/12/data/pg_hba.conf"
2020-06-29 09:03:31.822 CEST [11349] LOG: pg_hba.conf was not reloadedDans ce cas PostgreSQL continue de fonctionner mais avec l'ancienne version de pg_hba.conf.
Si vos tests ne fonctionnent pas, précisez quels sont les certificats que vous avez installés côté client ainsi que les message d'erreur à la connexion (de préférence avec psql) et les messages d'erreur correspondants dans le log de PostgreSQL.
Avec la collation fr-x-icu dans PostgreSQL 12, j'ai:
select x from t order by x collate "fr-x-icu";
x
--------
dé
dé a
dé m
dé z
dép
dép a
dép m
dép z
départ
dépbrt
dépzrt
(11 rows)Résultats identiques dans les versions 10 et 11.
A priori pas possible en version 9.5 ou 9.6.
Oui c'est possible. Il y a au moins 2 méthodes: soit réinstaller PG mais en prenant garde de ne P A S relancer un initdb qui pourrait écraser le répertoire PGDATA par défaut, soit copier le dossier PGDATA sur une autre machine dans un nouveau dossier où PG est installé.
Il faut en savoir plus, quelle est la version de PG utilisée, quel est le système cible (version Windows, distribution Linux précise), quel est l'installateur précis qui a été utilisé (yum, rpm, apt ou installateur graphique).
La première chose à faire avant tout c'est de sauvegarder PGDATA dans l'état actuel.
This is a French speaking only forum: if you cannot use French please use another English speaking forum such as Stack Overflow for example.
Il faudrait donner un exemple précis avec le code SQL de la vue matérialisée et de ses dépendances.
Mais je ne connais pas de commande SQL dans PostgreSQL qui va dans ce sens: la commande ALTER MATERIALIZED VIEW ne permet essentiellement que de renommer des colonnes d'après: https://docs.postgresql.fr/12/sql-alter … dview.html.
Voici une explication possible:
Table "public.t"
Column | Type | Collation | Nullable | Default
--------+--------------+-----------+----------+---------
cpa | character(8) | | |
cpb | integer | | |
insert into t values('12345', 12345);
INSERT 0 1
select cpa, cpb, length(cpa) as l_cpa, length(to_char(cpb,'99999')) as l_cpb, length(trim(to_char(cpb,'99999'))) as lt_cpb from t;
cpa | cpb | l_cpa | l_cpb | lt_cpb
----------+-------+-------+-------+--------
12345 | 12345 | 5 | 6 | 5
(1 row)
select cpa = to_char(cpb,'99999') from t;
?column?
----------
f
(1 row)
select cpa = trim(to_char(cpb,'99999')) from t;
?column?
----------
t
(1 row)La conversion avec TO_CHAR réserve un caractère pour le signe (un espace si le nombre est positif) et le test d'égalité retourne faux.
L'utilisation de TRIM supprime ce caractère et le test d'égalité retourne vrai.
Sur la page GitHub, certains semblent être arrivés à l'installer sur Windows soit directement (mais avec difficultés) soit en installant le package apt dans le système Linux de Windows:
https://github.com/dimitri/pgloader/issues/652
Sinon il existe toujours la possibilité d'avoir une machine virtuelle Linux sur Windows et d'y installer pgloader.
Ce fichier me semble correct. Si le service est bien démarré avec ce fichier au bon endroit, il devrait y avoir un log généré dans le répertoire pg_log.
Vérifiez qu'il n'y a pas d'erreur dans le journal des événements Windows au moment du démarrage du service.
Réinstaller PostgreSQL est risqué car vous risquez de perdre vos données dans PGDATA: sans sauvegarde c'est risqué.
C'est probablement une terminologie Oracle où l'outil de sauvegarde RMAN permet aussi de définir une période de rétention des sauvegardes. Si la sauvegarde a été supprimée du référentiel courant mais a été stockée auparavant ailleurs, elle peut être être réintégrée dans RMAN avec la commande CATALOG ce qui va permettre de la réutiliser par la suite avec la commande RMAN. Dans RMAN le catalogue est le référentiel qui enregistre les sauvegardes: il est stocké dans la base cible dans un format interne spécifique ou peut être stocké dans une vraie base séparée.
Les fichiers pga_hba.conf et postgresql.conf sont livrés avec beaucoup de commentaires: essayez de copier ces fichiers dans
c:\Program Files\PostgreSQL\9.0\data, de redémarrer le service PostgreSQL et de vérifier s'il y a log généré.
Je pense que c'est plus probablement un problème de droits d'accès dans Windows: essayez de lancer le service avec un compte qui a des droits "administrateur" idéalement il faudrait utiliser celui qui a installé PostgreSQL.
Même si la commande "net start" ne donne rien, le service Windows existe d'après la commande "sc query".
Les fichiers pg_hba.conf et postgresql.conf doivent impérativement être dans dans votre cas dans "PGDATA" càd dans
c:\Program Files\PostgreSQL\9.0\dataEssayez de déplacer ces 2 fichiers à cet endroit et de démarrer le service Windows de l'instance PG avec:
sc start postgresql-x64-9.0Est-ce qu'il y a des erreurs ?
Est-ce qu'il y a maintenant un log dans pg_log et si oui quel est son contenu ?
Pour vérifier que le service Windows de l'instance PostgreSQL est bien démarré, essayez la commande suivante (ici j'ai la version 9.3 installée sur Windows 2016):
> net start | findstr Post
postgresql-x64-9.3 - PostgreSQL Server 9.3Vous pouvez aussi tester avec la commamde sc query:
>sc query postgresql-x64-9.3
SERVICE_NAME: postgresql-x64-9.3
TYPE : 10 WIN32_OWN_PROCESS
STATE : 4 RUNNING
(STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0Dans votre cas, la commande doit être:
sc query postgresql-x64-9.0Ceci suppose le service Windows a le nom par défaut.
Ensuite il faut vérifier le log de l''instance qui doit se trouver par défaut dans
c:\Program Files\PostgreSQL\9.0\data\pg_logQuel est son contenu ?
Est-ce qu'il y a des erreurs ?
NB: le fait que d'être un abonné Free ne doit rien changer (à condition que vous parlez bien d'une installation locale sur votre machine Windws 10 et non du service PostgreSQL gratuit que Free fournit mais qui est disponible uniquement par l' interface web http://sql.free.fr/phpPgAdmin.
Pour installer une ancienne (ou une nouvelle) version de Postgres sur Linux, il est toujours possible de l'installer à partir du code source: https://docs.postgresql.fr/9.3/installation.html.
Sinon il est possible d'utiliser l'exécutable pg_dump 12 pour exporter la base source en version 9.3 et l'exécutable pg_restore 12 pour importer dans la base cible en version 12.
Je trouve la formulation de la documentation officielle assez ambigüe et qu'elle manque vraiment d'exemple sur ce point spécifique de changement de version:
Parce que pg_dump est utilisé pour transférer des données vers des nouvelles versions de PostgreSQL™, la sortie de pg_dump devra pouvoir se charger dans les versions du serveur PostgreSQL™ plus récentes que la version de pg_dump. pg_dump peut aussi extraire des données de serveurs PostgreSQL™ plus anciens que sa propre version. (À l'heure actuelle, les versions de serveurs supportées vont jusqu'à la 8.0.) Toutefois, pg_dump ne peut pas réaliser d'extraction de serveurs PostgreSQL™ plus récents que sa propre version majeure ; il refusera même d'essayer, plutôt que de risquer de fournir une extraction invalide. Par ailleurs, il n'est pas garanti que la sortie de pg_dump puisse être chargée dans un serveur d'une version majeure plus ancienne -- pas même si l'extraction a été faite à partir d'un serveur dans cette version. Charger un fichier d'extraction dans un serveur de version plus ancienne pourra requérir une édition manuelle du fichier pour supprimer les syntaxe incomprises de l'ancien serveur. L'utilisation de l'option --quote-all-identifiers est recommendée lors de l'utilisation avec des versions différentes, car cela permet d'empêcher la venue de problèmes provenant de listes de mots clés dans différentes versions de PostgreSQL™.
Vous pouvez essayer:
# select to_number('123456','999999')::int::oid;
to_number
-----------
123456
(1 row)Il y a 2 questions dans votre message:
- comment créer un serveur PostgreSQL répliqué sous Windows: c'est censé fonctionner comme sur Linux à part les spécificités Windows (syntaxe des noms de fichiers, service Windows pour l'instance/cluster)
- comment synchroniser les documents numérisés en dehors de la base: je ne sais pas si PostgreSQL sait faire ? En général on utilise des outils simples comme robocopy sur Windows ou rsync sur Linux ou des outils plus complexes comme DFS sur Windows ou DRBD sur Linux.
Que voulez-vous savoir en détail ?