Vous n'êtes pas identifié(e).
Mes commentaires:
Dans l'exemple cité, la manipulation de chaînes de caractères est effectivement bien plus facile qu'en C. Mais il faut savoir qu'une chaîne en Rust est un vrai type de données qui utilise Unicode et peut se révéler plus difficile à manipuler que l'équivalent en C qui est seulement en ASCII par défaut. Par exemple, essayez de mettre en majuscule le premier caractère d'une chaîne String.
Comme pour l'exécutable "Hello World", l'extension "Hello World" en mode debug est particulièrement volumineuse:
$ ll target/debug
total 86224
drwxrwxr-x. 32 pierre pierre 4096 Sep 28 15:31 build
drwxrwxr-x. 2 pierre pierre 20480 Sep 28 15:36 deps
drwxrwxr-x. 2 pierre pierre 6 Sep 28 15:31 examples
drwxrwxr-x. 4 pierre pierre 71 Sep 28 15:31 incremental
-rw-rw-r--. 1 pierre pierre 75 Sep 28 15:31 libworld.d
-rw-rw-r--. 2 pierre pierre 995514 Sep 28 15:33 libworld.rlib
-rwxrwxr-x. 2 pierre pierre 42444168 Sep 28 15:33 libworld.so
-rwxrwxr-x. 2 pierre pierre 44807552 Sep 28 15:36 pgrx_embed_world
-rw-rw-r--. 1 pierre pierre 137 Sep 28 15:36 pgrx_embed_world.d
$ ll target/release
total 628
drwxrwxr-x. 38 pierre pierre 4096 Sep 28 15:35 build
drwxrwxr-x. 2 pierre pierre 20480 Sep 28 15:36 deps
drwxrwxr-x. 2 pierre pierre 6 Sep 28 15:35 examples
drwxrwxr-x. 2 pierre pierre 6 Sep 28 15:35 incremental
-rw-rw-r--. 1 pierre pierre 77 Sep 28 15:36 libworld.d
-rw-rw-r--. 2 pierre pierre 113690 Sep 28 15:36 libworld.rlib
-rwxrwxr-x. 2 pierre pierre 493264 Sep 28 15:36 libworld.so
$ Bonjour Sébastien,
En effet pgbackrest ne peut restaurer qu'une seule base mais en écrasant les autres bases qui sont de fait inutilisables.
Cela ne permet donc pas de restaurer une seule base sans impact sur les autres bases. Est-ce qu'il y a un logiciel qui sait faire ça ?
Dommage que cet article ne mentionne pas que le fait d'utiliser un outil comme pgbackrest ne sait restaurer que toutes les bases de l'instance.
Dans l'exemple mentionné pgbackrest va restaurer les 3 bases applicatives b1, b2 et b3 ainsi que les bases "système" postgresql, template0 et template1 alors qu'idéalement on ne voudrait que restaurer la base b2.
Ceci n'est ni une limitation de pgbackrest (ni de barman d'ailleurs - même s'il n'est pas ici utilisé -) mais une limitation de PostgreSQL qui ne prend ni en compte la sauvegarde physique d'une base individuelle ni la restauration physique d'une base individuelle.
Cet article pourrait être complété en montrant :
- comment restaurer l'instance source dans une instance temporaire avec pgbackrest
- et ensuite comment utiliser pg_dump/pg_restore pour uniquement restaurer la base b2 de l'instance temporaire vers l'instance source.
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.