Vous n'êtes pas identifié(e).
Essayer de supprimer toutes les instructions pour CLIENT_ENCODING (ALTER ROLE intensetbm_admin SET client_encoding TO 'utf8'; et SET client_encoding TO 'utf8';) dans les scripts et retestez.
Je ne connais pas la "console SQL Shell": est-ce qu'il s'agit d'un logiciel connu ou d'une application maison ?
Si vous ne pouvez pas lancer cmd.exe directement il faut trouver une solution pour que votre console SQL Shell démarre avec l'instruction "chcp 1252" avant de lancer psql.exe ou une configuration équivalente dans Windows: à avoir avec votre administrateur côté poste de travail (Windows 10 sans doute) ?
Il faut lancer chcp dans une fenêtre interprête de commande comme cmd.exe et lancer psql dans la même fenêtre juste après.
Dans un premier temps vérifiez que CLIENT_ENCODING est bien positionné à 'WIN1252' par défaut avec:
show client_encodingAvant le lancer psql sur Windows, essayez d'exécuter:
chcp 1252Vérfiez ensuite:
1. l'avertissement de psql sur l'encodage console est-il toujours affiché ?
2. est-ce que le INSERT avec des caractères accentués fonctionne ?
Avec le client psql sur Windows, essayez de configurer l'encodage du client par rapport à la "code page" WIndows retournée par:
chcpSi vous avez 1252, essayer de configurer client_encoding avec:
set client_encoding to 'win1252';CLIENT_ENCODING définit le jeu du caractères du client connecté à PG.Je ne crois pas qu'il influe sur la création de la base.
Merci de nous donner le résultat de:
\l intensetbm;NB: SET NAMES est bien pris en compte par PG mais il est plus habituel d'utiliser SET CLIENT_ENCODING:
postgres=# set names 'SQL_ASCII';
SET
postgres=# show names;
ERROR: unrecognized configuration parameter "names"
postgres=# show client_encoding;
client_encoding
-----------------
SQL_ASCII
(1 row)
postgres=# A priori il faut
1. modifier le paramètre de l'instance password_encryption à la valeur
scram-sha-2562. modifier pg_hba.conf en conséquence.
3. Ensuite il doit suffire de créer un compte avec CREATE ROLE ou CREATE USER.
OK. Merci.
Vous pouvez aussi utiliser psql sur une machine locale - sans accès ssh à distance - pour une connexion à distance vers l'instance base de données Postgresql (ce qui suppose que le serveur Postgresql est correctement configuré ET sécurisé dans pg_hba.conf et que le port de l'instance est ouvert dans le pare-feu réseau). Ce type de fonctionnement est possible avec des hébergeurs gratuits mais limités comme https://www.elephantsql.com (mais pas chez Free qui ne donne que l'accès à la base PostgreSQL par une interface web).
J'ai trouvé l'adresse contact@postgresql.fr sur la page d'accueil https://www.postgresql.fr/.
J'entends par équipe d'animation les personnes qui mettent à jour le site (point du vue éditorial) et qui administrent le site (point de vue infra.).
La page https://www.postgresql.fr/asso/charte_d … munication utilise l'expression "L'équipe d'animateurs".
La même page dit:
L'équipe d'animation est autonome et ouverte aux membres actifs de la communauté francophone de PostgreSQL. Il n'est pas nécessaire d'être adhérent de l'association PostgreSQLFr pour faire partie de l'équipe. Les admissions se font par cooptation.
En fait je ne comprends pas s'il y a une différence entre les personnes qui gèrent le site et l'association PostgreSQL.fr ?
De façon générale, tout le monde peut-il mettre à jour l'ensemble de pages du site postgresql fr juste avec un compte sur le wiki sans être membre de l'association Postgresq.fr ni être membre de l'équipe d'animation ?
(je comprends bien que c'est le principe de base du wiki).
PS: Intéressant de savoir que le wiki choisi n'utilise pas de base de données.
Bonjour,
Le 2 mars j'ai envoyé un message à admin@postgresql.fr resté sans réponse. Le 4 mars j'ai envoyé un message à contact@posgresql.fr également resté sans réponse.
Dans ces messages j'ai écrit:
Bonjour,
Je souhaite faire partie de l'équipe d'animation de PostgreSQL.fr. Quelles sont les formalités à remplir ?
Je viens de modifier la page d'accueil pour mettre à jour les dernières versions dans le groupe Téléchargement avec mon compte pifor que j'avais utilisé pour l'instant uniquement pour le forum. Est-ce que ce type de modification est réservée à l'équipe d'animation ?
Je souhaite aussi savoir quel est le logiciel précis de Wiki utilisé par postgresql.fr ?
Est-il possible d'avoir une réponse ?
Merci.
Oui vous pouvez utiliser n'importe quel nom à condition qu 'il n'est pas déjà utilisé par une autre table dans le même schéma .
Si ce n'est pas déjà fait, par mesure de précaution, vous pouvez faire une sauvegarde à froid du répertoire PGDATA de l'instance (je suppose que tous les tablespaces sont bien dans PGDATA).
- bien arrêter l'instance normalement avec pg_ctl stop
- copier tous les fichiers PGDATA à froid avec la commande copy ou un copier/coller de l'explorateur Windows
- redémarrer l'instance avec pg_ctl start.
https://docs.postgresql.fr/9.6/upgrading.html dit:
18.6.1. Mettre à jour les données via pg_dumpall
Une méthode de mise à jour revient à sauvegarder les données d'une version majeure de PostgreSQL™ et de la recharger dans une autre -- pour cela, vous devez utiliser un outil de sauvegarde logique comme pg_dumpall ; une sauvegarde au niveau système de fichiers ne fonctionnera pas. Des vérifications sont faites pour vous empêcher d'utiliser un répertoire de données avec une version incompatible de PostgreSQL™, donc aucun mal ne sera fait si vous essayez de lancer un serveur d'une version majeure sur un répertoire de données créé par une autre version majeure.)
Il est recommandé d'utiliser les programmes pg_dump et pg_dumpall provenant de la nouvelle version de PostgreSQL™, pour bénéficier des améliorations apportées à ces programmes. Les versions actuelles de ces programmes peuvent lire des données provenant de tout serveur dont la version est supérieure ou égale à la 7.0.
L'hypothèse la plus probable est que le nom de la table est mal encodé dans le catalogue système.
Il faudrait essayer de renommer la table avec RENAME TABLE ou faire une mise à jour directe dans le catalogue système en accédant à la bonne ligne de PG_CLASS mais sans déclencher l'erreur d'encodage.
On peut essayer avec client_encoding='SQL_ASCII' et récupérer l'OID de la table pour faire l'UPDATE:
set client_encoding='SQL_ASCII';
SELECT pg_namespace.nspname, pg_class.oid, relname
FROM pg_class
JOIN pg_namespace
ON pg_class.relnamespace = pg_namespace.oid
AND pg_namespace.nspname='sh_tab_sp'
WHERE pg_class.relname LIKE 'l%'
ORDER BY relname;
BEGIN
UPDATE pg_class SET relname = 'nouveau_nom de la table' WHERE oid = <oid retourné par le SELECT pour la bonne table du bon schéma>;Lancer COMMIT que si on est sûr de la commande UPDATE (surtout ne pas oublier la clause WHERE sinon c'est la C A T A S T R O P H E dans le catalogue système !!!).
Si on n'est pas sûr lancer ROLLBACK.
Mais si la table a des index, le problème peut aussi être présent sur le nom des index ...
Je ne sais pas si VACUUM va changer que ce soit.
Oui Julien a raison: il faut d'abord se connecter à la base ma_db avec:
psql -U postgres ma_dbet ensuite dans cette session lancer les commandes SQL pour lister les tables du bon schéma.
Essayez d'afficher toutes les tables du schéma sh_tab_sp avec:
select pg_namespace.nspname, relname, convert_to(relname,'UTF8')
from pg_class
join pg_namespace
on pg_class.relnamespace = pg_namespace.oid
and pg_namespace.nspname='sh_tab_sp'
order by relname;Est-ce que pgAdmin affiche bien le schéma appelé sh_tab_sp dans la base en question ?
Est-ce que pgAdmin affiche correctement le nom des tables dans ce schéma et si oui comment est affiché le nom de table qui pose problème dans pg_dump ?
Quel est le résultat de la commande SQL:
show client_encodingQuel est le résultat de la commande Windows:
chcpIl est possible que le nom de la table dans le catalogue système soit mal encodé.
Essayez de lancer la commande SQL suivante pour vérifier le nom des tables (dans le schéma en question) qui commencent par le caractère 'l':
select pg_namespace.nspname, relname, convert_to(relname,'UTF8')
from pg_class
join pg_namespace
on pg_class.relnamespace = pg_namespace.oid
and pg_namespace.nspname='sh_tab_sp'
where relname like 'l%';Ce matin l'ensemble du site postgresql.fr a été indisponible. Est-il possible de savoir quelle était la cause de cette indisponibilité ?
Le site est-il est bien hébergé chez Gandi (au Luxembourg) ?
$ traceroute forums.postgresql.fr
traceroute to forums.postgresql.fr (46.226.108.58), 30 hops max, 60 byte packets
1 192.168.1.254 (192.168.1.254) 5.443 ms 5.420 ms 5.414 ms
2 obh67-2-78-214-250-254.fbx.proxad.net (78.214.250.254) 26.979 ms 30.042 ms 30.041 ms
3 213.228.17.126 (213.228.17.126) 32.374 ms 32.374 ms 38.110 ms
4 strasbourg-crs8-1-be1010.intf.routers.proxad.net (194.149.162.189) 41.227 ms 41.220 ms 41.219 ms
5 p11-crs16-1-be1109.intf.routers.proxad.net (194.149.160.197) 44.043 ms 44.043 ms 46.168 ms
6 194.149.166.54 (194.149.166.54) 46.168 ms 37.972 ms 37.926 ms
7 free-bzn.th2-1.rt.hopus.net (37.77.34.60) 39.909 ms 35.381 ms 34.903 ms
8 lag-th2-1.pa3-1.rt.hopus.net (37.77.32.11) 37.321 ms 37.258 ms 38.816 ms
9 gandi.pa3.hopus.net (37.77.38.5) 41.873 ms 41.819 ms 43.308 ms
10 core1-lux.mgt.gandi.net (217.70.176.102) 60.819 ms 60.805 ms 60.770 ms
11 xe3-x.dist2-lux.gandi.net (217.70.186.50) 56.999 ms xe3-x.dist1-lux.gandi.net (217.70.186.34) 63.240 ms 63.173 ms
12 celeste2.postgresql.fr (46.226.108.58) 65.367 ms 65.354 ms 67.275 msL'annnonce dit:
All PostgreSQL update releases are cumulative. As with other minor releases, users are not required to dump and reload their database or use pg_upgrade in order to apply this update release; you may simply shutdown PostgreSQL and update its binaries.
Il s'agit donc bien d'une mise à jour mineure et il n'est pas nécessaire de faire les mises à jour intermédiaires. Il suffit d'arrêter les instances et de mettre à jour les binaires (si les binaires ont été installés par les RPM officiels, un "yum update' peut suffire).
Les releases notes ne mentionnent que des corrections de bug pour FDW.
Avec PG 12.2 sur Linux cela marche sans problème avec la commande \copy de psql (qui est différente de la commande COPY côté serveur);
J'ai en entrée:
$ cat stat2019.txt
1;02/01/13et dans PG:
create table stat2019(x int, d date);
CREATE TABLE
postgres=# set datestyle='DMY';
SET
postgres=# \copy "stat2019" from 'stat2019.txt' delimiter ';';
COPY 1
postgres=# select * from stat2019;
x | d
---+------------
1 | 2013-01-02
(1 row)Il faudrait essayer d'utiliser l'outil EDITBIN livré avec Visual Studio d'après Atalsoft.
J'ai trouvé un message sur les listes de distribution PostgreSQL qui référence cet outil en 2005:message de 2005
PS. Pour ce type d'erreur il faut vraiment utiliser le forum StackOverflow 
Si après correction de postgresql.conf l'instance ne redémarre toujours pas, vous pouvez essayer de démarrer l'instance en mode mono-utilisateur, ce qui a l'avantage d'avoir le log affiché dans le shell courant (et non écrit dans $PGDATA/log) - bien penser à garder paramètre log_min_messages à DEBUG5.
Exemple:
$ postgres --single
2020-02-13 16:54:05.487 CET [10425] DEBUG: invoking IpcMemoryCreate(size=148545536)
2020-02-13 16:54:05.487 CET [10425] DEBUG: mmap(148897792) with MAP_HUGETLB failed, huge pages disabled: Cannot allocate memory
2020-02-13 16:54:05.536 CET [10425] DEBUG: SlruScanDirectory invoking callback on pg_notify/0000
2020-02-13 16:54:05.536 CET [10425] DEBUG: removing file "pg_notify/0000"
2020-02-13 16:54:05.536 CET [10425] DEBUG: dynamic shared memory system will support 288 segments
2020-02-13 16:54:05.536 CET [10425] DEBUG: created dynamic shared memory control segment 1071700630 (6928 bytes)
2020-02-13 16:54:05.536 CET [10425] DEBUG: InitPostgres
2020-02-13 16:54:05.536 CET [10425] DEBUG: my backend ID is 1
2020-02-13 16:54:05.536 CET [10425] LOG: database system shutdown was interrupted; last known up at 2020-02-13 15:25:51 CET
2020-02-13 16:54:05.676 CET [10425] DEBUG: checkpoint record is at 0/168FF40
2020-02-13 16:54:05.676 CET [10425] DEBUG: redo record is at 0/168FF40; shutdown TRUE
2020-02-13 16:54:05.676 CET [10425] DEBUG: next transaction ID: 0:555; next OID: 13809
2020-02-13 16:54:05.676 CET [10425] DEBUG: next MultiXactId: 1; next MultiXactOffset: 0
2020-02-13 16:54:05.676 CET [10425] DEBUG: oldest unfrozen transaction ID: 548, in database 1
2020-02-13 16:54:05.676 CET [10425] DEBUG: oldest MultiXactId: 1, in database 1
2020-02-13 16:54:05.676 CET [10425] DEBUG: commit timestamp Xid oldest/newest: 0/0
2020-02-13 16:54:05.676 CET [10425] DEBUG: transaction ID wrap limit is 2147484195, limited by database with OID 1
2020-02-13 16:54:05.676 CET [10425] DEBUG: MultiXactId wrap limit is 2147483648, limited by database with OID 1
2020-02-13 16:54:05.676 CET [10425] DEBUG: starting up replication slots
2020-02-13 16:54:05.676 CET [10425] DEBUG: starting up replication origin progress state
2020-02-13 16:54:05.676 CET [10425] LOG: database system was not properly shut down; automatic recovery in progress
2020-02-13 16:54:05.712 CET [10425] DEBUG: resetting unlogged relations: cleanup 1 init 0
2020-02-13 16:54:05.712 CET [10425] LOG: redo starts at 0/168FFB0
2020-02-13 16:54:05.884 CET [10425] DEBUG: could not open file "pg_wal/000000010000000000000002": No such file or directory
2020-02-13 16:54:05.884 CET [10425] LOG: redo done at 0/1FFFF90
2020-02-13 16:54:05.884 CET [10425] LOG: last completed transaction was at log time 2020-02-13 15:24:55.277015+01
2020-02-13 16:54:05.884 CET [10425] DEBUG: resetting unlogged relations: cleanup 0 init 1
2020-02-13 16:54:05.994 CET [10425] DEBUG: performing replication slot checkpoint
2020-02-13 16:54:06.449 CET [10425] DEBUG: creating and filling new WAL file
2020-02-13 16:54:06.453 CET [10425] PANIC: could not write to file "pg_wal/xlogtemp.10425": No space left on device
Aborted (core dumped)Pour afficher les n° de lignes dans vi entrer la commande:
:set nu Pour aller à un n° de ligne directement
:<numero de ligne>La syntaxe de log_line_prefix est documentée: https://www.postgresql.org/docs/10/runt … gging.html.
Il faut corriger l'erreur de syntaxe ligne 437 dans $PDATA/postgresql.conf car ce type d'erreur bloque le démarrage de l'instance.
Mais sinon je ne vois pas de cause qui peut expliquer les autres erreurs de démarrage.
Le .bash_profile me semble correct. Mais je mettrais quand même le chemin PG 10 en premier dans PATH et non en dernier:
PATH=/usr/pgsql-10/bin:$PATHIl y a peut-être quelque chose d'autre qui empêche les processus PG de démarrer correctement: SELinux ou autre chose ?
Il faut aussi vérifier s'il n'y a pas d'erreur dans /var/adm/messages concernant PG avec le compte root:
grep postgres /var/log/messagesJ'ai réussi à reproduire un problème similaire en saturant le système de fichiers qui contient $PGDATA: par exemple s'il est plein à 96%, j'ai les messages suivants:
-bash-4.2$ df -h /pgdata10
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/centos-pgdata 55M 48M 2.4M 96% /pgdata10
-bash-4.2$ pg_ctl stop
pg_ctl: PID file "/pgdata10/pgdata/postmaster.pid" does not exist
Is server running?
-bash-4.2$ pg_ctl start
waiting for server to start....2020-02-13 15:25:50.455 CET [7059] DEBUG: postgres: PostmasterMain: initial environment dump:
2020-02-13 15:25:50.455 CET [7059] DEBUG: -----------------------------------------
2020-02-13 15:25:50.455 CET [7059] DEBUG: XDG_VTNR=1
2020-02-13 15:25:50.455 CET [7059] DEBUG: XDG_SESSION_ID=1
2020-02-13 15:25:50.455 CET [7059] DEBUG: HOSTNAME=co7vb01.localdomain
2020-02-13 15:25:50.455 CET [7059] DEBUG: TERM=xterm-256color
2020-02-13 15:25:50.455 CET [7059] DEBUG: SHELL=/bin/bash
2020-02-13 15:25:50.455 CET [7059] DEBUG: HISTSIZE=1000
2020-02-13 15:25:50.455 CET [7059] DEBUG: PG_GRANDPARENT_PID=16076
2020-02-13 15:25:50.455 CET [7059] DEBUG: QTDIR=/usr/lib64/qt-3.3
2020-02-13 15:25:50.455 CET [7059] DEBUG: QTINC=/usr/lib64/qt-3.3/include
2020-02-13 15:25:50.455 CET [7059] DEBUG: QT_GRAPHICSSYSTEM_CHECKED=1
2020-02-13 15:25:50.455 CET [7059] DEBUG: USER=postgres
2020-02-13 15:25:50.455 CET [7059] DEBUG: LS_COLORS=rs=0:di=38;5;27:ln=38;5;51:mh=44;38;5;15:pi=40;38;5;11:so=38;5;13:do=38;5;5:bd=48;5;232;38;5;11:cd=48;5;232;38;5;3:or=48;5;232;38;5;9:mi=05;48;5;232;38;5;15:su=48;5;196;38;5;15:sg=48;5;11;38;5;16:ca=48;5;196;38;5;226:tw=48;5;10;38;5;16:ow=48;5;10;38;5;21:st=48;5;21;38;5;15:ex=38;5;34:*.tar=38;5;9:*.tgz=38;5;9:*.arc=38;5;9:*.arj=38;5;9:*.taz=38;5;9:*.lha=38;5;9:*.lz4=38;5;9:*.lzh=38;5;9:*.lzma=38;5;9:*.tlz=38;5;9:*.txz=38;5;9:*.tzo=38;5;9:*.t7z=38;5;9:*.zip=38;5;9:*.z=38;5;9:*.Z=38;5;9:*.dz=38;5;9:*.gz=38;5;9:*.lrz=38;5;9:*.lz=38;5;9:*.lzo=38;5;9:*.xz=38;5;9:*.bz2=38;5;9:*.bz=38;5;9:*.tbz=38;5;9:*.tbz2=38;5;9:*.tz=38;5;9:*.deb=38;5;9:*.rpm=38;5;9:*.jar=38;5;9:*.war=38;5;9:*.ear=38;5;9:*.sar=38;5;9:*.rar=38;5;9:*.alz=38;5;9:*.ace=38;5;9:*.zoo=38;5;9:*.cpio=38;5;9:*.7z=38;5;9:*.rz=38;5;9:*.cab=38;5;9:*.jpg=38;5;13:*.jpeg=38;5;13:*.gif=38;5;13:*.bmp=38;5;13:*.pbm=38;5;13:*.pgm=38;5;13:*.ppm=38;5;13:*.tga=38;5;13:*.xbm=38;5;13:*.xpm=38;5;13:*.tif=38;5;13:*.tiff=38;5;13:*.png=38;5;13:*.svg=38;5;13:*.svgz=38;5;13:*.mng=38;5;13:*.pcx=38;5;13:*.mov=38;5;13:*.mpg=38;5;13:*.mpeg=38;5;13:*.m2v=38;5;13:*.mkv=38;5;13:*.webm=38;5;13:*.ogm=38;5;13:*.mp4=38;5;13:*.m4v=38;5;13:*.mp4v=38;5;13:*.vob=38;5;13:*.qt=38;5;13:*.nuv=38;5;13:*.wmv=38;5;13:*.asf=38;5;13:*.rm=38;5;13:*.rmvb=38;5;13:*.flc=38;5;13:*.avi=38;5;13:*.fli=38;5;13:*.flv=38;5;13:*.gl=38;5;13:*.dl=38;5;13:*.xcf=38;5;13:*.xwd=38;5;13:*.yuv=38;5;13:*.cgm=38;5;13:*.emf=38;5;13:*.axv=38;5;13:*.anx=38;5;13:*.ogv=38;5;13:*.ogx=38;5;13:*.aac=38;5;45:*.au=38;5;45:*.flac=38;5;45:*.mid=38;5;45:*.midi=38;5;45:*.mka=38;5;45:*.mp3=38;5;45:*.mpc=38;5;45:*.ogg=38;5;45:*.ra=38;5;45:*.wav=38;5;45:*.axa=38;5;45:*.oga=38;5;45:*.spx=38;5;45:*.xspf=38;5;45:
2020-02-13 15:25:50.455 CET [7059] DEBUG: PGPORT=5510
2020-02-13 15:25:50.455 CET [7059] DEBUG: PATH=/usr/pgsql-10/bin:/usr/pgsql-10/bin:/usr/pgsql-10/bin:/usr/pgsql-10/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin
2020-02-13 15:25:50.456 CET [7059] DEBUG: MAIL=/var/spool/mail/postgres
2020-02-13 15:25:50.456 CET [7059] DEBUG: _=/usr/pgsql-10/bin/pg_ctl
2020-02-13 15:25:50.456 CET [7059] DEBUG: PWD=/var/lib/pgsql
2020-02-13 15:25:50.456 CET [7059] DEBUG: PGLOCALEDIR=/usr/pgsql-10/share/locale
2020-02-13 15:25:50.456 CET [7059] DEBUG: LANG=en_US.UTF-8
2020-02-13 15:25:50.456 CET [7059] DEBUG: KDEDIRS=/usr
2020-02-13 15:25:50.456 CET [7059] DEBUG: PGSYSCONFDIR=/etc/sysconfig/pgsql
2020-02-13 15:25:50.456 CET [7059] DEBUG: HISTCONTROL=ignoredups
2020-02-13 15:25:50.456 CET [7059] DEBUG: HOME=/var/lib/pgsql
2020-02-13 15:25:50.456 CET [7059] DEBUG: XDG_SEAT=seat0
2020-02-13 15:25:50.456 CET [7059] DEBUG: SHLVL=1
2020-02-13 15:25:50.456 CET [7059] DEBUG: LOGNAME=postgres
2020-02-13 15:25:50.456 CET [7059] DEBUG: QTLIB=/usr/lib64/qt-3.3/lib
2020-02-13 15:25:50.456 CET [7059] DEBUG: XDG_DATA_DIRS=/var/lib/pgsql/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
2020-02-13 15:25:50.456 CET [7059] DEBUG: LESSOPEN=||/usr/bin/lesspipe.sh %s
2020-02-13 15:25:50.456 CET [7059] DEBUG: PGDATA=/pgdata10/pgdata
2020-02-13 15:25:50.456 CET [7059] DEBUG: QT_PLUGIN_PATH=/usr/lib64/kde4/plugins:/usr/lib/kde4/plugins
2020-02-13 15:25:50.456 CET [7059] DEBUG: LC_COLLATE=en_US.UTF-8
2020-02-13 15:25:50.456 CET [7059] DEBUG: LC_CTYPE=en_US.UTF-8
2020-02-13 15:25:50.456 CET [7059] DEBUG: LC_MESSAGES=en_US.UTF-8
2020-02-13 15:25:50.456 CET [7059] DEBUG: LC_MONETARY=C
2020-02-13 15:25:50.456 CET [7059] DEBUG: LC_NUMERIC=C
2020-02-13 15:25:50.456 CET [7059] DEBUG: LC_TIME=C
2020-02-13 15:25:50.456 CET [7059] DEBUG: -----------------------------------------
2020-02-13 15:25:50.512 CET [7059] DEBUG: registering background worker "logical replication launcher"
2020-02-13 15:25:50.513 CET [7059] LOG: listening on IPv6 address "::1", port 5510
2020-02-13 15:25:50.513 CET [7059] LOG: listening on IPv4 address "127.0.0.1", port 5510
2020-02-13 15:25:50.603 CET [7059] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5510"
2020-02-13 15:25:50.713 CET [7059] LOG: listening on Unix socket "/tmp/.s.PGSQL.5510"
2020-02-13 15:25:50.713 CET [7059] DEBUG: invoking IpcMemoryCreate(size=148545536)
2020-02-13 15:25:50.714 CET [7059] DEBUG: mmap(148897792) with MAP_HUGETLB failed, huge pages disabled: Cannot allocate memory
2020-02-13 15:25:50.770 CET [7059] DEBUG: SlruScanDirectory invoking callback on pg_notify/0000
2020-02-13 15:25:50.770 CET [7059] DEBUG: removing file "pg_notify/0000"
2020-02-13 15:25:50.770 CET [7059] DEBUG: dynamic shared memory system will support 288 segments
2020-02-13 15:25:50.771 CET [7059] DEBUG: created dynamic shared memory control segment 1049831612 (6928 bytes)
2020-02-13 15:25:50.773 CET [7059] DEBUG: max_safe_fds = 983, usable_fds = 1000, already_open = 7
2020-02-13 15:25:50.774 CET [7059] LOG: redirecting log output to logging collector process
2020-02-13 15:25:50.774 CET [7059] HINT: Future log output will appear in directory "log".
...2020-02-13 15:25:54.292 CET [7060] DEBUG: logger shutting down
2020-02-13 15:25:54.292 CET [7060] DEBUG: shmem_exit(0): 0 before_shmem_exit callbacks to make
2020-02-13 15:25:54.292 CET [7060] DEBUG: shmem_exit(0): 0 on_shmem_exit callbacks to make
2020-02-13 15:25:54.292 CET [7060] DEBUG: proc_exit(0): 0 callbacks to make
2020-02-13 15:25:54.292 CET [7060] DEBUG: exit(0)
2020-02-13 15:25:54.292 CET [7060] DEBUG: shmem_exit(-1): 0 before_shmem_exit callbacks to make
2020-02-13 15:25:54.292 CET [7060] DEBUG: shmem_exit(-1): 0 on_shmem_exit callbacks to make
2020-02-13 15:25:54.292 CET [7060] DEBUG: proc_exit(-1): 0 callbacks to make
stopped waiting
pg_ctl: could not start server
Examine the log output.
-bash-4.2$ Vérifiez qu'il n'est pas (presque) plein avec:
$ df -h $PGDATA