Messages de lemjid

lemjid · Publications

Bonjour,

Vu dans la presse électronique:

Bruce Momjian:
https://www.postgresql.org/community/contributors/

Voici ce qu'il a déclaré:
https://www.developpez.com/actu/309521/ … e-Momjian/

Communiqué de EDB:

https://www.enterprisedb.com/news/edb-c … l-products
https://www.enterprisedb.com/blog/how-e … res-market

*** J'ai cru comprendre au début de mon expérience avec PostgreSQL 2009 que vu son organisation Il ne pourra pas subir le sors de MySQL!!! Les temps ont changés?
Si quelque pourra m'apporter (apporter aux utilisateurs PostgreSQL) une réponse.

Par avance Merci.

lemjid · Général

Bonjour,

Merci beaucoup "rjuju, pifor et gleu". Merci pour l’intérêt, la disponibilité et merci pour les réponses.

__________________________________________

Badreddine.

lemjid · Général

Merci Julien, c'est très intéressant ce que tu viens de dire et ça me convient parfaitement.
Si je me permet de te demander STP, je peux trouver quelque part "écrit, url...etc." ce que j'ai lu dans ton message:
(Seule la compatibilitré descendante est assurée, pas ascendante.).
Je précise que ce n'est pas pour mettre en cause ce que tu as dis bien au contraire.
Je voulais juste avoir un appui officiel pour faire valoir ceci.

lemjid · Général

Je suis désolé, je n'ai pas bien compris la question. Mais je dirais car le "create table ...with oids;" est toujours possible avec la V11.

[dvsgdas00b00004:postgres:pgserver02]$psql smart_engagement
psql (11.2)
Type "help" for help.

localhost:5433 postgres@smart_engagement=# create table t2 (c1 int) with oids;
CREATE TABLE
localhost:5433 postgres@smart_engagement=#

En tout cas initialement je suis en quête d'arguments techniques (explications) sur les recommandations de faire le dump avant mise à jour avec l'outil "pg_dump" de la version de destination?
C'est vraiment ce que je recherche précisément.

Merci pour votre aide

lemjid · Général

Bonjour,

Merci pour vos réponses.
Pour "rjuju", ce n'est pas la politique des M-à-J PostgreSQL que j'investigue.
J'essaie de comprendre (avec vos aides bien sur) les contraintes techniques qui nécessite cette recommandation.
Par exemple pour le V12. Je sais que la colonne OID à été enlevée. Que le "create table with OID" n'est plus possible.
Comme le pg_dump fait un select il vaut mieux faire le dump avec les binaires de la V12 pour upgrader une version inférieure. Pour moi c'est un argument claire, simple à comprendre et précis.
C'est ce que je recherche via ma requête.
Par avance Merci.

lemjid · Général

Bonjour,

J'ai vu plusieurs messages sur le net y compris celui-ci de guillaume L.:

"Il est à savoir qu'il n'y a aucune garantie par la communauté PostgreSQL qu'une sauvegarde réalisée avec un pg_dump en
version X puisse être restaurée en version X-1. Il est toujours conseillé de sauvegarder avec la version sur laquelle on veut restaurer."

Dans le forum PostgreSQLFr : https://forums.postgresql.fr/viewtopic.php?id=4879

En résumé, c'est conseillé dans le cas de mise à jours majeure de faire la sauvegarde via les outils (pg_dump, et pg_dumpall) en utilisant les binaires de la version de destination.

Mon souhait, est de comprendre les arguments de ce message (recommandation). Si possible s'il vous plait de me donner le liens dans le document officiel ou quelque chose similaire (wiki postgres, planete, site developpeurs PG...etc.) car sauf erreur de ma part, je n'ai pas vu ceci (en tout cas pour la version 9.6.x).

Par avance Merci.

lemjid · Général

Merci gleu.

lemjid · Optimisation

Merci gleu et merci rjuju.

lemjid · Optimisation

Merci dverite,

On m'a dit que c'est un "test de vie", c'est une sorte de 'select 1;'.
Si je comprend bien il faut inhiber ce test ou trouver le moyen de le corriger sans impact.

lemjid · Optimisation

Bonjour,

J'ai un message d'erreur qui se répète tout le temps dans les logs PG. ça prévenance de deux machines (Applicatifs).

"incomplete startup packet"

Dans la lecture je n'ai pas vraiment trouvé une solution claire pour résoudre ce problème. Je veux bien croire que ce n'ai pas très grave néanmoins il gonfle le fichier des logs et il le rend presque inexploitable (trop de messages qui se répètent).
Avez vous un retour d'expérience sur ce type de message SVP.

Par avance Merci.

lemjid · Général

Merci Julien.

T'as le lien direct au forum et/ou le site de la communauté pgbackrest?

lemjid · Général

Merci "dverite" pour ta réponse.

c'est claire et me conforte dans mes recherches et mes tests en revanche j'aimerai bien savoir s'il y a une combine pour réorienter les archives comme on veut.

Par avance Merci

lemjid · Général

Bonjour,
Est ce que quelqu'un pourra m'aider SVP!

lemjid · Général

Bonjour,

Après avoir installer pgbackrest, je me suis rendu compte qu'il archive les WALs sur le même FS que les backup.
Le paramètres "archive_command" dans postgresql.conf sera comme ceci.
archive_command = 'pgbackrest --stanza=bd_name archive-push %p'

Le paramètre "archive-push" est déjà prédéfini.
Est il possible de le modifier à la place de "%p" mettre un emplacement différent : "/emplecement/file_system/pg_archive"

Ou alors dans le fichier pgbackrest.conf, est il possible de définir l'archive-path comme c'est le cas pour le "repo-path"?

Par avance Merci

lemjid · Sécurité

Bonjour,

En dehors de l'authentification gssapi, dans PostgreSQL, les noms d'identifiants sont toujours converti en minuscules, sauf si vous entourez le nom de l'identifiant avec des guillemets doubles. exemple "MATRICULE_UTILISATEUR".
C'est la même chose pour les relations de la base.

https://www.postgresql.org/docs/current … xical.html
https://docs.postgresql.fr/9.6/sql-synt … ence-table

lemjid · Sécurité

Bonjour,

Je reviens vers vous pour un retour d'expérience sur des produits Open-Source (pour PostgreSQL) permettant au minimum de tracer:
Les connexions.
Les dumps de données
Des modifications de privilèges.
...
Le but est d'exporter ces informations en temps réel afin de générer des alertes.
Je ne sais pas si quelqu'un parmi vous a utilisé des outils comme:
PgAudit, McAfee Audit Plugin...etc ou bien d'autres.

Quel est votre avis et vos conseils bien sure?
Par avance MERCI.

lemjid · Optimisation

C'était ça le vrai problème. Après un rollback de la transaction préparé ça à marché.

Merci beaucoup Julien pour ton aide.

Bon week-end

lemjid · Optimisation

Bonjour,

En effet il y en a deux:
select transaction, prepared, database from pg_prepared_xacts ;
transaction | prepared | database
---------------+------------------------------- +----------
55790841 | 2017-06-14 08:35:37.905075+02 | xyz01
55790842 | 2017-06-14 08:38:04.791443+02 | xyz01
(2 rows)
=====
Désolé mais la transaction préparé elle prend un verrou?!
Comment faire si oui ?

lemjid · Optimisation

D'accord,

Mais la colonne "age" c'est la '32150' qui est plus ancienne (00:00:08.007351 contre 00:00:06.977733)?!
Dans le doute j'ai refait la manip et voilà le résultat:

lemjid · Optimisation

Merci encore "rjuju".

Le problème c'est que dans les locks il n'y a rien, mais ma requête reste en attente en attente de verrou.
Ce qui est plus étonnant, j'ai redémarré la base et j'ai coupé toutes les connexions, les connexions (applicatives) aussi. Je lance un reindex sur cette table, elle se met à attendre un verrou même le process dans "/proc/xxxxx/status il est en waiting.
Voilà ce qui pose problème. S'il y a un UPDATE ou une tâche qui verrouille la table, ça sera compréhensible mais là rien (Voir la capture de dessus).

Une question: Est ce que la dépendance d'une table peut jouer? Le fait d'avoir un trigger dessus qui appelle cette fonction...?
CREATE OR REPLACE FUNCTION public.nx_log_acls_modified()
RETURNS trigger
LANGUAGE plpgsql
AS $function$
-- Trigger to log change in the acls table
DECLARE
doc_id varchar(36);
BEGIN
IF (TG_OP = 'DELETE') THEN
doc_id := OLD.id;
ELSE
doc_id := NEW.id;
END IF;
INSERT INTO hierarchy_modified_acl VALUES(doc_id, 'f');
RETURN NEW;
END $function$
Par avance merci!

lemjid · Optimisation

A vrai dire c'est une routine, mais justifié car il y a un bloat sur quelques tables 'actives'. Pas de mesure dans le sens comparatif avec les vacuum/analyze simple. En revanche je ne me souviens pas avoir vu les inconvénients du "vacuum full' sur la version 8.4 et j'aimerai bien avoir un lien ou un titre ou autre...etc

On peut abandonner l'idée du vacuum full mais à un moment donnée il faut peut être faire un reindex un moment ou un autre.

Le problème c'est impossible de prendre le verrou sur cette maudite table il est toujours en attente d'acquisition (granted=f). Aucun moyen de forcer le 'pg_try_advisory_lock' ou 'begin; lock table.....;' et impossible de voir le verrous est détenu par qui????? et c'est le centre de mon problème.

lemjid · Optimisation

Bonjour "rjuju"

Merci pour ta réactivité. Je comprend tout à fait ta réponse (je m'ai attend). Tu comprends bien qu'il y a des solution du long, moyen et court terme. Mon souhait et de trouver un issue à ce problème tout en travaillant pour convaincre ceux qui ont habilité de prendre la décision pour la migration. Tu sais aussi mieux que moi que dans certaines structures c'est fastidieux pour bouger déjà une ligne de code qui est là depuis un certain temps... Bref c'est un autre sujet.

As tu STP (au une autre personne), une idée pour ce cas.

Par avance merci.

lemjid · Optimisation

Bonjour à toutes et à tous,

lemjid · Général

Bonjour Julien,

Je ne sais pas grand choses. Mais peut être c'est un pbm hardware dont je n'ai pas des éléments dessus. Tout ce que je peux confirmer c'est qu'il ya eu un reboot.
reboot system boot 3.2.13-grsec-xxx Mon Mar 14 03:47 - 14:03 (10:15)

lemjid · Général

oups! jai' oublié
timezone = 'Europe/Paris'

La même chose.

#1 Publications » PostgreSQL Sera t-il mangé comme MySQL?! » 15/10/2020 15:19:16

#2 Re : Général » Mise à jour PostgreSQL » 06/03/2020 14:48:07

#3 Re : Général » Mise à jour PostgreSQL » 05/03/2020 17:16:45

#4 Re : Général » Mise à jour PostgreSQL » 05/03/2020 16:06:36

#5 Re : Général » Mise à jour PostgreSQL » 05/03/2020 12:39:08

#6 Général » Mise à jour PostgreSQL » 04/03/2020 19:02:56

#7 Re : Général » Sauvegarde avec PGBACKREST. » 09/05/2019 15:10:41

#8 Re : Optimisation » Message d'erreur dans les logs pg » 09/05/2019 15:09:22

#9 Re : Optimisation » Message d'erreur dans les logs pg » 25/04/2019 14:24:08

#10 Optimisation » Message d'erreur dans les logs pg » 25/04/2019 12:09:04

#11 Re : Général » Sauvegarde avec PGBACKREST. » 25/04/2019 11:54:53

#12 Re : Général » Sauvegarde avec PGBACKREST. » 19/04/2019 17:17:35

#13 Re : Général » Sauvegarde avec PGBACKREST. » 19/04/2019 15:33:18

#14 Général » Sauvegarde avec PGBACKREST. » 18/04/2019 20:43:34

#15 Re : Sécurité » Problème d'authentification gssapi avec compte en majuscule » 26/03/2019 17:23:36

#16 Sécurité » sécurisation et supervision » 26/03/2019 16:55:51

#17 Re : Optimisation » maintenance_postgresql face aux locks » 11/08/2017 14:44:59

#18 Re : Optimisation » maintenance_postgresql face aux locks » 11/08/2017 11:33:24

#19 Re : Optimisation » maintenance_postgresql face aux locks » 11/08/2017 10:42:13

#20 Re : Optimisation » maintenance_postgresql face aux locks » 10/08/2017 17:24:00

#21 Re : Optimisation » maintenance_postgresql face aux locks » 10/08/2017 12:34:36

#22 Re : Optimisation » maintenance_postgresql face aux locks » 10/08/2017 10:33:14

#23 Optimisation » maintenance_postgresql face aux locks » 09/08/2017 16:47:36

#24 Re : Général » Log POstgreSQL » 14/03/2016 15:17:18

#25 Re : Général » Log POstgreSQL » 14/03/2016 13:08:50

Pied de page des forums

PostgreSQL.fr

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux