Concernant les performances, cette nouvelle version perpétue la montée en puissance de la branche 8 avec un lot de nouvelles fonctionnalités très intéressantes :
- La technologie HOT (Heap Only Tuples) ;
- L'auto-optimisation du processus d'écriture en tâche de fond ;
- La validation asynchrone ;
- L'étalement des points de vérification ;
- Les parcours synchronisés ;
- La réduction des en-têtes varlena ;
- La protection du parcours du cache L2 ;
- L'assignation paresseuse des XID.
- La journalisation applicative au format CSV ;
- SQL/XML ;
- Le support de MS Visual C++ ;
- La gestion des ENUM ;
- La recherche textuelle intégrée ;
- SSPI & GSSAPI ;
- Les tableaux de types composés ;
- pg_standby.
![[en]](../images/en.png)
PostgreSQL (358 hits)![[fr]](../images/fr.png)
Dossier de presse (348 hits)-
Matrice des fonctionnalités (304 hits)
-
Annonce officielle (112 hits)
-
Notes de versions (113 hits)
-
Association PostgreSQLFR (397 hits)
> Lire la dépêche (66 commentaires, moyenne: 3,2).
Vous avez demandé le commentaire #902767.
Run by 
Cette page a été générée par Templeet en 0.0665s (dont 0.0061 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Yo
Bonne récap mon petit ioio ;)
J'en profite pour demander si quelqu'un à une experience Samba / postrgre pour un domaine doz à la place de Samba / LDAP. Ca semble interessant mais mal documenté...
Kaf.
[^]Ploup
> Bonne récap mon petit ioio ;)
Merci mon grand kak^WCoco :)
> J'en profite pour demander si quelqu'un à une experience Samba / postrgre
> pour un domaine doz à la place de Samba / LDAP. Ca semble interessant
> mais mal documenté...
Oui, malheureusement...Samba a abandonné les backend db et un projet à emergé pour "maintenir" la chose : http://pdbsql.sourceforge.net/
Mais effectivement la doc et les exemples y sont trés pauvre et pas à jour...
Il reste toujours un Samba / LDAP / PgSQL qui lui semble un peu mieux documenté :)
ioguix
[^]Re: Yo
euh, question ingénue, mais quel est l'intérêt d'un Samba / Postgre par rapport à un Samba / LDAP?
[^]Re: Yo
Virer LDAP ?
Bon, sinon, à part ça, oui LDAP est utile pour mutualiser des choses et des services comme l'authentification, mais parfois, adns ce dernier cas, PAM peut trés bien suffir aussi pour faire la colle avec une simple base.
De plus, LDAP reposant sur une base de donnée, pourquoi se priver de virer ce protocol supplémentaire si le SI en question le permet ? Et justement ce pourrait être le cas de Kaf si le module pdbsql était un peu mieux supporté/documenté...
Mais il faut croire que la norme est à Samba/LDAP depuis les fameux scripts smbldap et pour se rapprocher au mieux d'Active Directory je suppose...
ioguix
[^]Re: Yo
ben ldap a d'autres intérêt par rapport à une bd : un annuaire est censé etre plus efficace en lecture seule, alors qu'une bd est plus conçu dans un sens de lecture/écriture.
Je ne dis pas que postgresql ne peut pas convenir, je dis que la philosophie derrière est légèrement différente.
Ensuite LDAP est très souvent utilisé pour l'authentification en entreprise, ce qui peut expliquer son couplement avec samba.
Question conne :
Il est très facile de faire des attributs multivalués avec du LDAP. (par exemple : liste des alias de messagerie d'un user).
Sous postgres, on est obligé de prendre
- des tableaux ? (c'est sql ou postgres only les tableaux dans postgres ?)
- de faire une jointure ?
Ou il y a une autre méthode ?
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Yo
De plus, LDAP reposant sur une base de donnée, pourquoi se priver de virer ce protocol supplémentaire
Parce que nombre d'applicatifs causent nativement le LDAP et beaucoup moins causent nativement "ton" schéma de stockage des utilisateurs sur PG?
[^]Re: Yo
Tu peux aussi me citer en entier, tu notera que j'avais pourtant bien précisé "si le SI en question le permet" (SI: Système d'Information, au cas où hein)...
Et puis pas mal d'applications ont des extensions permettant d'authentifier sur une base SQL, nativement en pgsql ou via ODBC par exemple.
Maintenant, si vous voulez coller du LDAP à tous les étages même dans une entreprise n'en ayant pas le besoin hein...Perso LDAP ne me sort pas encore totalement par la tête...Mais allez en parler à Kaf :)
ioguix
[^]Re: Yo
Tu peux aussi me citer en entier, tu notera que j'avais pourtant bien précisé "si le SI en question le permet" (SI: Système d'Information, au cas où hein)...
C'est vrai, mais ta précondition avait vraiment des allures de poudre verte... ("citez moi une raison pour ne pas remplacer LDAP par PG, dès lors qu'il n'y a aucune raison pour garder LDAP", en substance).
Pour la standardisation (de fait) des accès DB en lieu et place de LDAP, c'est vrai que ça commence à venir, mais le moins qu'on puisse est que c'est tout sauf unifié. Pire que LDAP, c'est dire :>
[^]Re: Yo
Et puis pas mal d'applications ont des extensions permettant d'authentifier sur une base SQL, nativement en pgsql ou via ODBC par exemple.
Le "pas mal" est quand même assez vague, et en plus on dépend de la base de donnée. Le gros avantage de LDAP reste quand même son haut niveau d'interropérabilité. J'ai eu pas mal de projets à gérer avec du LDAP (web, messagerie, authent OS,...) et franchement, pour rien au monde je n'aurai mis une base de donnée SQL avec. Avec LDAP, j'ai des schemas standardisés donc pas la peine de se triturer l'esprit pour les attributs. Pour ce qui de se rapprocher d'AD, je rappelle quand même que les authent sur LDAP sont arrivées sur les Unix bien avant AD.
Et je ne parle même pas des perfs....
[^]Re: Yo
J'ai bossé dans une grosse boite ou le nombre de serveurs unix était assez conséquent, et pour déployer massivement les comptes certains ot eu l'idée de faire appel à une solution propriétaire, nécessitant une usine à gaz Java pour fonctionner, avec extraction de données d el'annuaire LDAP pour les injecter dans la base et n tas de trucs bizarre, alors qu'en utilisant l'annuaire LDAP, ça aurait fait la m^^eme chose et ^coûté moins cher.
[^]Re: Yo
C'est bon, c'est bon, n'en jetez plus, je ne suis pas un anti-LDAP non plus hein...
Ceci dit merci à vous pour vos info diverses (histoire de lecture plus efficace et param multi-valeurs), j'ai été me documenter un peu plus là dessus et me suis rendu compte d'une chose qui m'avait *bien* échappée (chkreugneugneu) jusqu'ici : Berckley DB n'est pas une base de données au même sens que les bases SQL bien connues...
..Et là, beaucoup de choses s'expliques du coup :)
ioguix
[^]Re: Yo
C'est bon, c'est bon, n'en jetez plus, je ne suis pas un anti-LDAP non plus hein...
Tu réagis mal ....
[^]Re: Yo
ioguix, t'es pas tout seul... :)
moi non plus je n'aime pas trop LDAP et LDAP j'en reviens franchement. Je bosse dans une université où on a mis en place un annuaire openLDAP pour la gestion des comptes utilisateurs , auth sur un portail web pour accès intranet ( SSO via CAS) et plus spécifiquement la messagerie dont je m'occupe
notre SI est basé sur du MySQL (je rentre pas dans le débat MySQL vs Postgres, je reconnais des qualités indéniables à Postgres, mais on a choisi MySQL et on en est très content) et un annuaire LDAP "norme SUPANN" pour ceux qui connaissent (avec 20000 étudiants et 1500 personnels derrière)
j'ai eu bien des déboires avec OpenLDAP (sous woody puis sarge), avec des démons slapd qui se cassait la gueule sans raison apparente, ou qui grossissaient grossissaient.
Encore très récemment une mauvaise expérience : coupure electrique, le serveur MySQL repars sans problème, le serveur LDAP (sur la meme machine) : HS et faut y aller à coup de db_recover en virant les logs (et en priant) sinon ça plante tjs
on parle de performances ? quand je vois la misère (temps de traitement) pour faire des modifications de données online (à chaud) par traitement par lot par rapport à MySQL, même pas la peine... On en est à un point où on supprime et regénère en offline chaque nuit l'annuaire LDAP à partir des bases MySQL, mais de plus en plus notre backend principal devient la base MySQL et non plus l'annuaire LDAP car la confiance dans sa stabilité n'y est plus
je vous parle pas non plus du côté penible de la syntaxe en ligne de commande pour faire la moindre modification, suppression avec des dn long comme mon bras. avec une GUI, Vous connaissez surement phpldapadmin, et ben j'essaie meme plus de m'en servir, dès que je clique sur la branche 'people', le sablier tourne, tourne, tourne et tourne encore,
Non franchement je suis vacciné de LDAP , j'ai pourtant persévéré mais je suis vacciné et désormais je m'appuie sur un backend MySQL quand je peux
auth CAS + MySQL pour le web
postfix + courier-imap avec auth MySQL
proftpd + MySQL
me reste un radius relié au LDAP à transformer en radius + MySQL
Effectivement reste plus que Samba qui reste assez lié à LDAP pour de l'auth centralisé mais je me dit qu'avec pam_mysql ou pam_pgsql
si qqu'un a déjà mis en place ce genre de choses, samba+pam+bdd (postgres ou mysql) j'suis preneur de liens
C'est peut-etre l'avantage de MySQL sur Postgres : une plus grande facilité de connectivité possible (avec souvent des paquets *-mysql sous Debian) avec les outils qui nécessite de l'authentification utilisateurs (postfix, courier, radius, serveurs ftp etc etc)
voilà pour mon expérience
a+
Linux : il y a moins bien mais c'est plus cher
[^]Re: Yo
C'est triste ton point de vue sur LDAP.