Vous n'êtes pas identifié(e).
Bonjour tout le monde,
Tout d'abord vu la situation actuelle, j'espère que vous allez tous bien ainsi que vos entourages respectifs.
Je suis en quête d'une méthode et/ou un outil qui réorganise les relations de la base PostgreSQL et qui m'épargne les désagréments de VACUUM FULL à savoir les locks avec des bases de données de plus en plus exigeants en terme de disponibilité.
L’extension pg_repack, est un bon compromis, mais à part l'espace disque à fournir en plus pour le faire fonctionner. Ceci n'est pas très grave, le support magnétique n'est pas ce qui coûte le plus chère.
Le problème c'est qu'en cherchant, je trouve une publication de "DALIBO" disant ceci "pg_repack étant très intrusif et ayant déjà affiché des bugs de corruption de données, nous déconseillons fortement son utilisation." Fin de Citation.
A savoir que pour les versions <=1.1.8, il ne faut pas lancer des DDL au moment ou pg_repack fait sont travail car il y a un risque sérieux de corruption de données à défaut d'un rollback.
Ma question est : La recommandation de BALIBO concerne t elle les anciennes version ou elle est toujours d'actualité.
Est ce que quelqu'un utilise l’outil "pg_repack en production "surtout pour des base à grande taille >=500Go, pourra partager son/ses expérience.
Par avance merci
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.
Bonjour,
Merci beaucoup "rjuju, pifor et gleu". Merci pour l’intérêt, la disponibilité et merci pour les réponses.
__________________________________________
Badreddine.
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.
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
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.
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.
Merci gleu.
Merci gleu et merci rjuju.
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.
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.
Merci Julien.
T'as le lien direct au forum et/ou le site de la communauté pgbackrest?
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
Bonjour,
Est ce que quelqu'un pourra m'aider SVP!
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
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
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.
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
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 ?
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:
pmbd01=# SELECT
procpid, usename,
(now() - query_start) as age,
c.relname,
l.mode,
l.granted from
pg_stat_activity a
left outer join pg_locks l
on (a.procpid = l.pid)
left outer join pg_class c
on (l.relation = c.oid)
where
c.relname !~ '^pg_'
order by
pid;
procpid | usename | age | relname | mode | granted
---------+----------+-----------------+---------+---------------------+---------
27613 | postgres | 00:01:40.860525 | acls | AccessExclusiveLock | f
(1 row)
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!
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.
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.
Bonjour à toutes et à tous,
J'ai une version pg 8.4 sur linux redhat 4.1
PostgreSQL 8.4.4 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20071124 (Red Hat 4.1.2-42), 64-bit
jusqu'à là rien n'est très grave. Mon problème c'est que la tâche de maintenance (vacuum full/reindex...) automatisées pas crontab restent bloquées sur une table. Le blocage est logique car la table en question attend un verrou exclusif.
Voici le résultat après une tentative de reindex : (la table en question 'acls')
procpid | usename | age | relname | mode | granted
---------+--------------+-----------------+-----------------------------+---------------------+---------
31964 | pmbd01update | 00:00:06.977733 | hierarchy_primarytype_idx | AccessShareLock | t
31964 | pmbd01update | 00:00:06.977733 | hierarchy_parentid_name_idx | AccessShareLock | t
31964 | pmbd01update | 00:00:06.977733 | acls | AccessShareLock | t
31964 | pmbd01update | 00:00:06.977733 | common | AccessShareLock | t
31964 | pmbd01update | 00:00:06.977733 | locks_pk | AccessShareLock | t
31964 | pmbd01update | 00:00:06.977733 | dc_contributors | AccessShareLock | t
31964 | pmbd01update | 00:00:06.977733 | dublincore | AccessShareLock | t
31964 | pmbd01update | 00:00:06.977733 | locks | AccessShareLock | t
31964 | pmbd01update | 00:00:06.977733 | proxies | AccessShareLock | t
31964 | pmbd01update | 00:00:06.977733 | proxies_targetid_idx | AccessShareLock | t
31964 | pmbd01update | 00:00:06.977733 | proxies_versionableid_idx | AccessShareLock | t
31964 | pmbd01update | 00:00:06.977733 | proxies_pk | AccessShareLock | t
31964 | pmbd01update | 00:00:06.977733 | common_pk | AccessShareLock | t
31964 | pmbd01update | 00:00:06.977733 | dublincore_pk | AccessShareLock | t
31964 | pmbd01update | 00:00:06.977733 | hierarchy | AccessShareLock | t
31964 | pmbd01update | 00:00:06.977733 | acls_id_idx | AccessShareLock | f
31964 | pmbd01update | 00:00:06.977733 | dc_contributors_id_idx | AccessShareLock | t
31964 | pmbd01update | 00:00:06.977733 | hierarchy_pk | AccessShareLock | t
31964 | pmbd01update | 00:00:06.977733 | hierarchy_parentid_idx | AccessShareLock | t
32150 | postgres | 00:00:08.007351 | acls | ShareLock | t
32150 | postgres | 00:00:08.007351 | acls_id_idx | AccessExclusiveLock | f
=============
Ce qui me pose problème c'est que à chaque fois que je lance un 'vacuum full' ou 'reindex' sur la table ou l'index de 'acls', des verrous sortent partout comme dans l'exemple ou plus (ça peut rester bloqué une éternité) alors qu'avant le tout est en sommeil aucune connexion, aucune requête en cours.
================
Voici la définition de la table:
Column | Type | Modifiers | Storage | Description
------------+------------------------+-----------+----------+-------------
id | character varying(36) | not null | extended |
pos | integer | | plain |
name | character varying(250) | | extended |
grant | boolean | | plain |
permission | character varying(250) | | extended |
user | character varying(250) | | extended |
group | character varying(250) | | extended |
Indexes:
"acls_id_idx" btree (id), tablespace "tbs_pmbd01_index"
Foreign-key constraints:
"acls_id_hierarchy_fk" FOREIGN KEY (id) REFERENCES hierarchy(id) ON DELETE CASCADE
Triggers:
nx_trig_acls_modified AFTER INSERT OR DELETE OR UPDATE ON acls FOR EACH ROW EXECUTE PROCEDURE nx_log_acls_modified()
Has OIDs: no
Tablespace: "tbs_pmbd01_data"
========================
J'ai tenté un disable trigger puis reindex ==> NOK.
j'ai tenté aussi de faire create index concurrently, le problème qu'avec la version 8.4 on ne peut pas faire un "drop index concurrently"!!!
...
Tout simplement je ne trouve pas quel est le meilleur chemin à prendre pour résoudre ce problème.
Quelqu'un pourra m'aiguiller SVP, par avance merci.
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)
