Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#51 Re : Général » Mise à jour PostgreSQL » 04/03/2020 19:35:32
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.
#52 Re : Général » [RESOLU] Sauvegarde échoue avec erreur séquence d'octets invalide » 04/03/2020 19:08:25
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.
#53 Re : Général » [RESOLU] Sauvegarde échoue avec erreur séquence d'octets invalide » 04/03/2020 16:35:55
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.
#54 Re : Général » [RESOLU] Sauvegarde échoue avec erreur séquence d'octets invalide » 04/03/2020 16:11:44
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 ?
#55 Re : Général » [RESOLU] Sauvegarde échoue avec erreur séquence d'octets invalide » 04/03/2020 12:35:20
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%';#56 Site PostgreSQL.fr » indisponibilité postgresql.fr » 02/03/2020 17:55:27
- pifor
- Réponses : 1
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 ms#57 Re : Installation » mise à jour vesion 10.6 vers 10.12 » 21/02/2020 11:23:22
L'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.
#58 Re : Site PostgreSQL.fr » ERREUR: syntaxe en entrée invalide pour le type date » 20/02/2020 18:32:49
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)#59 Re : Optimisation » Equivalent Windows de ulimit pour augmenter max_stack_depth » 20/02/2020 18:21:01
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 
#60 Re : Général » problème de server » 13/02/2020 17:57:15
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)#61 Re : Général » problème de server » 13/02/2020 17:47:29
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.
#62 Re : Général » problème de server » 13/02/2020 17:26:57
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.
#63 Re : Général » problème de server » 13/02/2020 16:59:56
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/messages#64 Re : Général » problème de server » 13/02/2020 16:31:10
J'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#65 Re : Général » problème de server » 13/02/2020 15:53:15
Merci pour toutes les informations.
Cependant les différents logs ne me permettent pas de conclure: d'après le dernier log il y a eu une restauration des bases de l'instance à l'état du 23-01 qui s'est bien passée. Je ne vois pas d'erreur qui explique pourquoi l'instance ne peut pas redémarrer. Mais ce dernier log ne comporte pas de traces de niveau DEBUG5: je ne suis pas sûr que c'est vraiment le bon log ???
Les logs ne sont pas horodatés: je suggère de rajouter "%m" dans le paramètre log_line_prefix "%m user=%u-database=%d-host=%h=> ' " dans $PGDATA/postgresql.conf et d'essayer de redémarrer l'instance et de voir si le fichier log est bien modifié avec le nouveau format de trace.
#66 Re : Général » problème de server » 13/02/2020 14:26:59
En comparant avec un démarrage d'instance PG version 10.11 sur CentOS 7.7.1908 et avec le même niveau de trace, la piste que je voie c'est un problème avec le processus logger:
user=-database=-host==> DEBUG: logger shutting downIl faut le contenu du dernier log dans $PGDATA/log et le fichier de configuration $PGDATA/postgresql.conf pour en savoir plus.
#67 Re : Général » problème de server » 13/02/2020 11:37:50
Le fichier $PGDATA/postmaster.pid est créé automatiquement au démarrage de l'instance PG et est supprimé automatiquement à l'arrêt de l'instance. Il ne faut pas le modifier ou le supprimer manuellement.
S'il n'est pas là, cela veut normalement dire que l'instance PG a été arrêtée.
Pour analyser votre problème, essayez de modifier dans $PGDATA/postgresql.conf le paramètre log_min_messages:
log_min_messages = debug5 Dans le shell, avec le compte postgres:
1. vérifiez bien que PGDATA pointe bien sur le répertoire de la base PG 10 et que PATH contient bien les exécutables PG10:
-bash-4.2$ echo $PGDATA
/var/lib/pgsql/10/data
-bash-4.2$ echo $PATH
/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
-bash-4.2$ 2. essayer de démarrer l'instance avec :
pg_ctl start3. envoyez le contenu de la sortie de "pg_ctl start" et du log qui est dans $PGDATA/log qui doivent nous donner plus de détails si l'instance ne démarre pas.
#68 Re : Général » problème de server » 11/02/2020 18:59:36
Pouvez-vous afficher le contenu du dernier log dans $PGDATA/log ?
Quel est le résultat de la commande ls -al /var/lib/pgsql/10/data ?
Ce problème peut arriver s'il y a plusieurs versions PG installées avec plusieurs instances différentes dans des répertoires PGDATA différents et que vous essayer d'accéder à l'instance avec une mauvaise valeur de PGDATA.: il faut aussi vérifier le contenu des variables d'environnement PGDATA et PATH et qu'il n'y pas une autre instance PG démarrée.
#69 Re : Général » Erreur pg_restore "opérateur n'existe pas" » 26/06/2019 16:23:17
C'est bien pg_restore 9.4.4 qui est utilisé. PostGIS est bien installé dans le schéma public.
On a aussi du retard dans la version de postGIS: j'ai réussi à faire fonctionner pg_restore en utilisant une version plus récente d'une fonction:
diff postgis--2.1.8.sql.26062019 postgis--2.1.8.sql
3461c3461
< AS 'SELECT $1 && $2 AND _ST_Intersects($1,$2)'
---
> AS 'SELECT $1 OPERATOR(@extschema@.&&) $2 AND @extschema@._ST_Intersects($1,$2)'et en modifiant le paramètrage de l'extension:
diff postgis.control.26062019 postgis.control
5c5,6
< relocatable = true
---
> relocatable = false
> schema = public#70 Général » Erreur pg_restore "opérateur n'existe pas" » 26/06/2019 09:52:10
- pifor
- Réponses : 2
Bonjour
Nous utilisons :
# select version();
version
---------------------------------------------------------------------------------------------------------------
PostgreSQL 9.4.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16), 64-bit
(1 ligne)avec:
# select postgis_full_version();
NOTICE: Function postgis_topology_scripts_installed() not found. Is topology support enabled and topology.sql installed?
postgis_full_version
----------------------------------------------------------------------------------------------------------------------------------------------------
POSTGIS="2.1.8 r13780" GEOS="3.4.2-CAPI-1.8.2 r3921" PROJ="Rel. 4.9.1, 04 March 2015" GDAL="GDAL 1.9.2, released 2012/10/08" LIBXML="2.7.6" RASTER
(1 ligne)Nous exportons une base avec pg_dump et nous l'importons avec pg_restore.
Avant de lancer pg_restore, je supprime la base cible et je la recrée vide.
Le pg_restore est lancé sans option particulière:
pg_restore -v -d <base> -h <hostname> -p <port> -U <compte superuser> <fichier dump>.pg_restore a plusieurs erreurs du type suivant:
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: l'opérateur n'existe pas : public.geometry && public.geometry
LIGNE 1 : SELECT $1 && $2 AND _ST_Intersects($1,$2)
^
ASTUCE : Aucun opérateur ne correspond au nom donné et aux types d'arguments.
Vous devez ajouter des conversions explicites de type.
REQUÊTE : SELECT $1 && $2 AND _ST_Intersects($1,$2)
CONTEXTE : fonction SQL « st_intersects » durant « inlining »
La commande était : CREATE MATERIALIZED VIEW dr_vue_cons_geo_zone_batie_hors_zae AS
WITH zone_bati_hors_zae AS (
SELECT sbat.gid,
...
La base source et la base cible ont exactement la même version PostgreSQL et la même version de PostGIS.
On est bloqué sur cette erreur car la seule référence que j'ai trouvé pour ce type d'erreur est liée à des upgrades mais on ne fait pas d'upgrade.
Est-ce que quelqu'un a une piste ?
Merci.
#71 Re : Général » Padawan recherche conseils » 25/02/2019 12:49:22
Bonjour,
L'utilisation d'un outil en ligne comme SQL Fiddle permet d'utiliser une base de données sans avoir rien à installer à condition d'accepter les contraintes suivantes
- interface en anglais
- version utilisée qui date un peu
- pas de droits de type administrateur.
#72 Re : PL/pgSQL » parametrer un script a partir d'un fichier texte » 22/11/2018 12:47:01
Vous pouvez essayer de passer les paramètres avec l'option -v de psql:
Exemple:
psql -a -vparam_b=true -vparam_i=123 -vparam_t="'titre rapport'" -f tv.sqlavec tv.sql:
select :param_b as "param_b";
select :param_i as "param_i";
select :param_t as "param_t";
\qL'exécution donne:
select :param_b as "param_b";
param_b
---------
t
(1 row)
select :param_i as "param_i";
param_i
---------
123
(1 row)
select :param_t as "param_t";
param_t
---------------
titre rapport
(1 row)
\q