Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 Re : Général » valeur renvoyée par now() différente selon d'ou vient l'appel » 31/10/2019 11:20:22
Merci pour le retour
#2 Général » valeur renvoyée par now() différente selon d'ou vient l'appel » 30/10/2019 18:57:35
- dev.isc84
- Réponses : 2
Bonjour,
je viens de m'appercevoir d'une chose que je n'arrive pas à expliquer:
Je crée une table :
CREATE TABLE public.temp_test_zone(
col1 timestamp without time zone DEFAULT now(),
col2 timestamp with time zone DEFAULT now(),
libelle text
);
Il est 17h00 heure française.
Depuis une ligne de commande via psql, je fais un insert into temp_test_zone(libelle) values ('test1');
J'ai comme résultat col2 : 16:00:00.000000+00 et col1 16:00:00.000000
(même résultat depuis un pgadmin sur un poste client)
Je fais cette même requête depuis un connecteur java JDBC:
J'ai comme résultat col2 : 16:00:00.000000+00 et col1 17:00:00.000000
Auriez vous une explication au fait que depuis un psql la valeur without time zone soit différente de celle obtenue depuis un connecteur JDBC?
Je précise que le linux sur lequel tourne postgres est à l'heure française aussi.
Merci pour vos éclaircissements!
#3 Re : Général » Upgrade 9.6 vers 11 » 19/11/2018 11:06:56
Ok merci de votre aide!
#4 Re : Général » Upgrade 9.6 vers 11 » 16/11/2018 17:14:23
ça n'est utilisé sur aucune base.
L'idéal c'est donc un drop manuel des fonctions, opérateurs et du type?
#5 Re : Général » Upgrade 9.6 vers 11 » 15/11/2018 12:24:18
C'est assez surprenant, l'extension est visible via select * from pg_available_extensions , mais n'est pas installée.
Donc pas moyen de faire un drop extension
Pourtant j'ai bien les fonctions et le type dans la base (la base a été créée en v7 à l'époque il me semble, ça a peut etre un lien)
J'hésite à faire un create extension chkpass suivi d'un drop de l'extension ou faire des drop des méthodes, opérateurs et du type à la main. On est sur une base de prod... je ne voudrais pas faire d'erreurs.
Que me conseillez vous?
#6 Re : Général » Upgrade 9.6 vers 11 » 14/11/2018 12:12:04
Il ne me semble pas. J'aurais d'autres erreurs si c''était le cas non?
#7 Re : Général » Upgrade 9.6 vers 11 » 14/11/2018 11:17:14
Le module chkpass n'est plus présent dans la V11, je viens de lire dans la doc de la release 11 que c'est voulu par soucis de sécurité si j'ai bien compris.
Mais son absence me génère 15 erreurs sur le restore:
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: n'a pas pu accéder au fichier « $libdir/chkpass » : No such file or directory
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: la fonction public.chkpass_in(cstring) n'existe pas
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: n'a pas pu accéder au fichier « $libdir/chkpass » : No such file or directory
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: la fonction public.chkpass_out(public.chkpass) n'existe pas
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: la fonction public.chkpass_in(cstring) n'existe pas
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: n'a pas pu accéder au fichier « $libdir/chkpass » : No such file or directory
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: la fonction public.eq(public.chkpass, text) n'existe pas
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: n'a pas pu accéder au fichier « $libdir/chkpass » : No such file or directory
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: la fonction public.ne(public.chkpass, text) n'existe pas
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: n'a pas pu accéder au fichier « $libdir/chkpass » : No such file or directory
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: la fonction public.raw(public.chkpass) n'existe pas
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: le type « public.chkpass » est seulement un shell
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: l'opérateur n'existe pas : public.chkpass public.<> text
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: le type « public.chkpass » est seulement un shell
pg_restore: [programme d'archivage (db)] could not execute query: ERREUR: l'opérateur n'existe pas : public.chkpass public.= text
Quelle procédure conviendrais pour ces problèmes? Faut-il ajouter un module?
#8 Re : Général » Upgrade 9.6 vers 11 » 14/11/2018 09:40:40
parfait, merci pour votre aide.
#9 Re : Général » Upgrade 9.6 vers 11 » 13/11/2018 11:06:03
Merci pour l'information Guillaume, on va juste faire un restore parallélisé alors.
On est sur une infra virtialisée avec des disques NVMe.
On se demandait:
1) y a-t-il une distribution linux à privilégier (actuellement nous sommes sous Debian)
2) Comment profiter au max des disques NVMe? Je pensais baisser le random_page_cost à une valeur proche de 1 vu la rapidité des disques. Qu'en pensez vous? Y aurait-il un autre paramètre à retoucher selon vous?
Merci d'avance
Olivier Bouiron
#10 Général » Upgrade 9.6 vers 11 » 12/11/2018 17:49:28
- dev.isc84
- Réponses : 17
Bonjour,
Nous sommes actuellement en 9.6 et souhaitons upgrader vers pg11.
Notre base pèse environ 60GB, ce qui prend un peu de temps pour le restore.
On pensait à créer un nouveau serveur en v11, se servir du PITR pour initialiser puis mettre à jour cette base. Ensuite le moment venu, déconnecter les clients, jouer les wall en attente puis rediriger les clients de la 9.6 vers la 11.
Ca permettrait de bloquer les utilisateurs un minimum de temps.
Est-ce envisageable comme solution? (PITR entre deux versions majeures possible?)
Sinon, auriez vous une autre idée svp?
Merci de votre aide!
Pages : 1