Vous n'êtes pas identifié(e).
Bonjour,
Je commence par répondre un peu à côté... il me semble que votre besoin soit couvert par l'extension PGAudit : https://www.pgaudit.org/ .... Pourquoi ne pas l'utiliser, plutôt que de redévelopper tout de votre côté?...
En particulier, dans la doc, vous trouverez tout ce qui peut être logué par PGAudit : https://github.com/pgaudit/pgaudit/blob … pgauditlog
Bien à vous,
Jean-Paul
Bonjour Benoît,
Je ne connais pas d'IHM pour pgBackRest... Au sens où un client permettrait de faire une configuration, lancer un backup ou autre...
En revanche, pour pgBackRest comme tous les autres outils de backup&restore, il existe beaucoup d'outils permettant de surveiller leur activité (monitoring). À mon sens c'est plus important qu'une IHM, car très généralement, pgBackRest fonctionne en tâche de fonds, et c'est assez rare qu'on ait à l'utiliser.
Et quand bien même, la ligne de commande a un principe assez simple: pgbackrest, stanza et opération à effectuer..
À vous lire si vous aviez des demandes particulières,
Jean-Paul
Bonjour,
Vous utilisez une version bien trop obsolète... Mon premier conseil serait de mettre à jour dès que possible dans une version supérieure à la 13, si possible, car celle ci sera obsolète à son tour dans une petite année...
Bon courage.
jpa
Bonjour,
Tout comme Sébastien, je n'ai (plus) aucun intérêt à dire ça, mais je partage son avis à 100%...
Y'a pas débat :-)
Pour vous faire une idée: https://public.dalibo.com/exports/formation/ tout est là
jpa
Bonjour à toutes et à tous,
Crunchy Data France recrute des profils "Solutions Architect" : https://crunchydata.applytojob.com/appl … -Architect. Aidez nos clients à bâtir avec eux la meilleure infrastructure de données pour leurs besoins. Le tout en Open Source bien évidemment. Nous utilisons toutes les technologies en vogue autour de PostgreSQL pour améliorer son déploiement (ansible, playbooks, ...) et ce y compris avec les technologies de conteneurisation (Kubernetes au sein de RH OpenShift ou pas, ...)... le tout avec des niveaux de sécurité très importants.
Travail en "remote", avec quelques déplacements clients à prévoir de temps en temps (principalement en Île de France (80% du temps)). "Package complet" et très intéressant!
N'hésitez pas à parcourir le site web de la société, en anglais uniquement pour le moment (l'activité de Crunchy Data France a démarré le 3 janvier 2022!) : https://www.crunchydata.com/
Jetez un œil à l'équipe, ça vaut le détour, aussi : https://www.crunchydata.com/team/
Vous travaillerez dans mon équipe, et en français la plupart du temps. Nous aurons à travailler avec nos collègues de part le monde aussi, l'anglais est donc exigé.
Quant à PostgreSQL, si vous lisez ceci sur ce forum, et bien, je ne devrais pas avoir à vous donner trop d'explications :-)
Au plaisir,
Ok,
Je regarde ça, merci pour la piste Daniel !
Comme tu vois j'essaie de me dégager un peu de temps pour (re)faire un peu d'admin de PG.fr histoire d'aider une équipe qui en a bien besoin, et aussi parce que ça me fait plaisir :-)
Je vous tiens au courant...Par contre, ma bande passante est limitée, d'une part, et d'autre part, je vais en référer à l'équipe, pour que j 'en sois officiellement chargé ! 
A+
Bonjour par ici,
Je suis sur le truc du coup. Mais mauvaise nouvelle: l'aggregateur planet utilisé est très (très) vieux, peut-être même pas maintenu..
Même l'auto test renvoie des erreurs :-/ (cf ci-dessous).
J'ai testé en changeant http// en https// pour certains, car avec letsencrypt etc, il y a désormais des redir automatiques du genre http->https.. mais ça n'est pas ça le problème.
Bref, je regarde ça en détails, et surtout, comment faire autrement, avec un soft un peu plus récent 
PS: si vous avez des idées je prends :-)... juste j'attaque :-)
# ./runtests.py
.....................................................................................FF.ERROR:planet:Error 500 while updating feed <planet/tests/data/before.atom>
FERROR:planet:Error 500 while updating feed <planet/tests/data/before.atom>
ERROR:planet:Error 500 while updating feed <planet/tests/data/after.atom> (formerly <planet/tests/data/before.atom>)
FERROR:planet:Error 500 while updating feed <planet/tests/data/before.rss>
E
======================================================================
ERROR: test_update_with_no_date (planet.tests.test_sub.SubTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/var/www/planete.postgresql.fr/planet/tests/test_sub.py", line 63, in test_update_with_no_date
item=channel._items.values()[0]
IndexError: list index out of range
======================================================================
FAIL: test_82 (planet.tests.test_sanitize.SanitizeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/var/www/planete.postgresql.fr/planet/tests/test_sanitize.py", line 15, in <lambda>
func = lambda self: self.assertEqual(sanitize.HTML(a), b)
AssertionError: '<a title=""">quote</a>' != '<a title=""">quote</a>'
======================================================================
FAIL: test_83 (planet.tests.test_sanitize.SanitizeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/var/www/planete.postgresql.fr/planet/tests/test_sanitize.py", line 15, in <lambda>
func = lambda self: self.assertEqual(sanitize.HTML(a), b)
AssertionError: '<a title="\'">quote</a>' != '<a title="'">quote</a>'
======================================================================
FAIL: test_fetch (planet.tests.test_sub.SubTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/var/www/planete.postgresql.fr/planet/tests/test_sub.py", line 32, in test_fetch
self.assertEqual(len(items_list), 1)
AssertionError: 0 != 1
======================================================================
FAIL: test_update_with_new_date (planet.tests.test_sub.SubTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/var/www/planete.postgresql.fr/planet/tests/test_sub.py", line 51, in test_update_with_new_date
self.assertEqual(len(items_list), 1)
AssertionError: 0 != 1
----------------------------------------------------------------------
Ran 91 tests in 0.097s
FAILED (failures=4, errors=1)Bonjour,
C'est pour un devoir à la maison c'est ça?
Bonne journée,
Bonjour intmail,
J'ai vu passer Enveloppe (http://www.envelope.xyz/index.html).. Ça vous demandera un peu de code mais je pense que ça peut le faire pour obtenir très rapidement un formulaire de saisie ?
Il y a aussi VFront (http://www.vfront.org/index.php), qui fera ça encore plus simplement... le résultat ressemble à des formulaires de saisie automatique "à la access"...
Et deux pointeurs pour encore plus de projets dans ce style:
* https://wiki.postgresql.org/wiki/Commun … _GUI_Tools
* http://www.postgresonline.com/journal/i … pment.html
Voilà les seules idées qui me passent par la tête.
Tenez-nous au courant de vos tests ici même ça pourra servir à d'autres.
Merci,
Re,
Pouvez vous poster un exemple de données/structure de la table géo?
Sans cela j'aurai du mal à reproduire de mon côté;
Bien à vous,
RE,
D'ailleurs je me dis que cette jointure est bien curieuse, ... et que faire un coalesce après un sum aussi
Voici donc ce que je vous propose:
SELECT
periode.libelle AS periode,
sum(coalesce(st_length(geo.the_geom),0)) AS length
FROM periode
LEFT JOIN geo ON geo.date = periode.date
WHERE geo.insee = '086009'
and ((geo.date BETWEEN periode.debut AND periode.fin) or (geo.date is null))
GROUP BY periode.libelle, periode.gid
ORDER BY periode.gid DESC ;
... en supposant que vos dates sont des entiers pleins genre 2014 d'un côté et 2014 de l'autre...
... si ça n'était pas le cas:
LEFT JOIN geo ON extract(year from geo.date) = periode.date
... voilà
SELECT
periode.libelle AS periode,
coalesce(sum(st_length(geo.the_geom)), 0) AS length
FROM periode
LEFT JOIN geo ON geo.date
WHERE geo.insee = '086009'
and ((geo.date BETWEEN periode.debut AND periode.fin) or (geo.date is null))
GROUP BY periode.libelle, periode.gid
ORDER BY periode.gid DESC ;
... donne quoi?
Re, voir le commentaire modifié entre temps plus haut:
* de changer le where en : WHERE (geo.insee = '086009' or geo.insee is null)
Bonjour,
J'ai lu en diagonale, mais.. à tout hasard, avez-vous essayé :
* de remplacer LEFT par RIGHT?
* de changer le where en : WHERE (geo.insee = '086009' or geo.insee is null)
(pas trop le temps de vous répondre plus là :-(... plus tard peut-être)
Bien à vous,
Bonjour à tous,
La salon Solution Linux se tiendra au CNIT les 20 et 21 mai prochains.
Comme d'habitude la communauté francophone de PostgreSQL aura un stand.
Si vous comptez nous aider à tenir le stand, pouvez-vous m'envoyer un message et me dire quelle demi-journée (voire jour-s! soyons fous!) vous serez présent et votre taille (S, M, L, XL, 2XL, 3XL..).
L'idée est que chaque personne sur le stand soit facilement identifiable par les visiteurs comme faisant partie du stand, et pour ce faire, le mieux est d'avoir tous le même polo ou tshirt: on vous le fournira :-)
Pour suivre l'évolution des préparatifs c'est par ici: http://wiki.postgresql.fr/sl2014:accueil
J'insiste sur le fait qu'il n'est pas nécessaire d'être un super expert de PostgreSQL pour répondre aux questions du public. Vous seriez même surpris par les questions qu'on nous pose la plupart du temps !
Quel que soit votre intérêt pour PostgreSQL, j'espère que plusieurs d'entre vous répondront présent. Nous sommes vraiment trop peu nombreux chaque année pour tenir le stand, et nous vivons donc parfois des journées un peu longues.
Si vous vous êtes toujours demandé comment vous pourriez contribuer à la communauté PostgreSQL, et bien, donnez-lui une demi-journée, et venez rencontrer la communauté en vrai sur le stand !
Merci à tous,
Monsieur Brouard,
Le commentaire ci-dessous provoque chez moi stupeur et questions.
[...] il se trouve que je travaille et hier j'étais chez Alstom, un de mes clients, oub comme par hasard nous allons passer d'une base PostGreSQL qui donne des performances lamentables à une base SQL Server.... [...]
Stupeur, tout d'abord, car je trouve très moyen qu'en grand professionnel de l'informatique auto-proclamé vous vous permettiez de raconter ce que vous faites chez vos clients. De notre côté, nous signons des accords de confidentialité, comme par exemple, avec l'industrie. Peu importe, ce point ne regarde que vous.
Questions, ensuite: pouvez-vous nous en dire un peu plus sur ce cas d'utilisation? C'est à dire expliquer concrètement ce que vous avez mis en œuvre pour résoudre les problèmes liés à PostreSQL chez ce client? À moins que ce dernier n'ait choisi de migrer à SQL Server pour d'autres raisons que celle que vous invoquez? Quoi qu'il en soit, merci de vous en tenir aux faits.
Ah, et, si possible, des faits réels, car vous avez une fâcheuse tendance à l'affabulation, comme vous l'avez démontré au sujet du site "Le Bon Coin" (voir vos propos péremptoires ici : http://forums.postgresql.fr/viewtopic.p … 126#p19126, démentis par l'un des responsables techniques du même site ici : http://forums.postgresql.fr/viewtopic.p … 137#p19137 (et suivants)).
Bien à vous,
Bonjour Jean-Louis,
Merci pour cette clarification! Une fois de plus "SQLPro" est pris la main dans le sac... Pas très grave, on commence à connaître le personnage par ici.
Quant au témoignage de Christophe, que j'avais eu le plaisir d'interviewer à l'époque, je suis tout à fait disposé à le revoir, ou l'avoir au téléphone (peu importe àmha), afin de le mettre à jour, tant il a été déterminant pour d'autres DSI et autres DI qui hésitaient à essayer (au moins) PostgreSQL.
À vous lire,
Bonjour,
Cela ressemble à du code exécuté pour faire une mise à jour de schéma, suite à une mise à jour de version applicative ou quelque chose comme ça, non ?
Pouvez-vous nous en dire un peu plus sur le contexte?
Bien à vous,
Bonjour «Jeremiel»,
Gilles nous fait vous dire que ce bug est corrigé depuis ce week-end. Il vous demande donc de télécharger le code depuis le github..
Soit, ici: https://github.com/darold/ora2pg
Bien à vous,
Salut Youssef, Salut à tous!
Ça a été fort sympathique hier soir... Dommage pour ceux qui ont loupé le coche !
Il y aura d'autres événements comme celui-là tout au long de l'année, l'objectif étant bien sûr de se faire rencontrer des utilisateurs de PostgreSQL et les laisser échanger sur le sujet 
Restés connectés ;-)
À bientôt,
Bonjour à tous!
Merci à ceux et celles qui ont répondu favorablement à cette proposition, d'une façon ou d'une autre, sur l'un des multiples canaux de communication que j'avais proposé
Voici donc le lieu (sans surprises pour beaucoup d'entre vous!):
Hall's Beer Tavern
68 Rue Saint-Denis
75001 Paris 1er arrondissement
Tel: 01 42 36 92 72
(Châtelet - Les Halles)Je vous propose un RDV là bas à ce soir, le mardi 18 septembre à 20h00 !
Je pense que l'on doit être plusieurs à connaître plutôt bien cet endroit.
Au plaisir de vous y retrouver ce soir,
Bonjour marcandre,
Pour ma part, je préfère faire appel à l'utilitaire "psql" pour faire des extractions de données dans un fichier plutôt que d'utiliser l'ordre SQL COPY.
La raison est simple: lorsque vous utilisez COPY comme l'a conseillé justement Guillaume ci-dessus, vous devez le faire dans un cadre très strict. En effet "fichier" devra être situé où l'utilisateur "postgres" à qui appartient les processus de PostgreSQL a accès.
Si vous voulez vous affranchir de ces problèmes de droit, alors, faites le avec votre utilisateur traditionnel, en utilisant toujours copy, mais celui de psql comme suit:
$ psql -c "\copy (select ...) to 'fichier' CSV;" mabaseOù "mabase" est votre base de données, et où j'ai supposé que l'utilisateur courant du système y avait accès, via la boucle locale.
Voilà pour cette petite astuce, toute bête mais bien pratique !
Bien à vous,
Bonjour Damalaan,
Je me suis bien amusé avec celui là
J'ai créé une table de test comme suit:
create table test3 (t_date date, t_integer integer); ...que j'ai ensuite remplie avec des dates aléatoires entre 2011 et 2012 (pour avoir une période "à cheval"), et un entier fixe (1).
J'ai ensuite créée la requête suivante:
select pairs.somme+impairs.somme as total, pairs.annee, pairs.mois, impairs.annee, impairs.mois
from
(select sum(t_integer) as somme, extract(year from t_date)::integer as annee, extract(month from t_date)::integer as mois
from test3 where extract(month from t_date)::integer%2=1
group by 2,3 order by 2,3) impairs,
(select sum(t_integer) as somme, extract(year from t_date)::integer as annee, extract(month from t_date)::integer as mois
from test3 where extract(month from t_date)::integer%2=0
group by 2,3 order by 2,3) pairs
where
((impairs.mois=pairs.mois+1
and impairs.annee=pairs.annee))
or (pairs.mois=12 and impairs.mois=1 and pairs.annee=impairs.annee-1)
order by pairs.annee, pairs.mois;Ou je fais les sommes d'un côté des mois pairs et de l'autre les mois impairs.
Ensuite, je joins sur le mois / mois+1 de la même année, et avec le cas spécial (le OR) du mois de décembre et du mois de janvier, où pour eux l'année est l'année-1 de l'autre...
Je fais un order by pour que ça soit plus lisible, voici le résultat:
total | annee | mois | annee | mois
-------+-------+------+-------+------
16 | 2011 | 2 | 2011 | 3
24 | 2011 | 4 | 2011 | 5
17 | 2011 | 6 | 2011 | 7
21 | 2011 | 8 | 2011 | 9
27 | 2011 | 10 | 2011 | 11
17 | 2011 | 12 | 2012 | 1
58 | 2012 | 2 | 2012 | 3
52 | 2012 | 4 | 2012 | 5
69 | 2012 | 6 | 2012 | 7
63 | 2012 | 8 | 2012 | 9
65 | 2012 | 10 | 2012 | 11
(11 rows)Voilà, je pense que ça répond à votre énoncé ?
Merci de revenir vers nous de toute façon que vous arriviez ou non à transposer cet exemple dans votre cas d'utilisation.
Bonne journée,