IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

PostgreSQL Discussion :

Depuis 20 ans, PostgreSQL aurait mal utilisé fsync(), compromettant la cohérence des données enregistrées


Sujet :

PostgreSQL

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Dirigeant
    Inscrit en
    Juin 2016
    Messages
    3 160
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Dirigeant
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2016
    Messages : 3 160
    Points : 66 249
    Points
    66 249
    Par défaut Depuis 20 ans, PostgreSQL aurait mal utilisé fsync(), compromettant la cohérence des données enregistrées
    Depuis 20 ans, PostgreSQL aurait mal utilisé fsync(), compromettant la cohérence des données,
    des solutions ont été proposées au FOSDEM 2019

    C’est au FOSDEM de cette année qui a eu lieu ces 2 et 3 février à Bruxelles que le sujet a été abordé à nouveau par Thomas Vondra, un ingénieur de base de données et contributeur au projet PostgreSQL. Il s’agit de l’implémentation de fsync au sein du gestionnaire de base de données PostgreSQL. D’après ces propos, fsync() ne marche pas réellement comme on le pense sur Linux et d’autres systèmes BSD et peut ainsi avoir des conséquences potentiellement désastreuses pour la durabilité/cohérence des données.

    Le paramètre fsync() permet de transférer toutes les données internes modifiées d’un fichier référencé par le descripteur de fichier fd (c'est-à-dire les pages de cache tampon modifiées) vers le périphérique de disque (ou un autre périphérique de stockage permanent), de sorte que toutes les informations modifiées puissent être récupérées même après une panne du système ou son redémarrage. Cela inclut l'écriture ou le vidage d'un cache de disque, le cas échéant. L'appel est bloqué jusqu'à ce que l'appareil signale que le transfert est terminé. Seulement, ce n’est pas exactement ce que fait la fonction avec le serveur de base de données PostgreSQL.

    Si ce paramètre est activé, indique la documentation du serveur PostgreSQL, ce dernier essayera de s’assurer que les mises à jour sont écrites physiquement sur le disque en émettant des appels fsync() système ou diverses méthodes équivalentes. Cela garantit que le cluster de base de données peut retrouver un état cohérent après une panne matérielle ou du système d'exploitation. Toujours dans cette documentation, il est noté que, bien que la désactivation de fsync() soit souvent un avantage en termes de performances, cela peut entraîner une corruption irrémédiable des données en cas de panne de courant ou de panne du système.

    Il est donc conseillé de désactiver cette fonction fsync si vous pouvez facilement recréer toute votre base de données à partir de données externes dans le cas contraire ne le faites pas. Le problème abordé par Vondra a été signalé pour la première fois en mars de l’année dernière par Craig Ringer, un ingénieur en base de données. Il prévenait que la gestion des erreurs fsync() par PostgreSQL est dangereuse et risque de provoquer une perte de données sur XFR. Ensuite Jonathan Corbet, un autre ingénieur en base de données a apporté plus d’explications sur le sujet en avril dernier.

    Nom : index.png
Affichages : 20104
Taille : 42,3 Ko

    PostgreSQL, dit-il, suppose qu’un appel réussi à fsync() indique que toutes les données écrites depuis le dernier appel réussi sont passées en toute sécurité au stockage persistant. Mais ce n'est pas ce que fait le noyau. Lorsqu'une écriture d'E/S en mémoire tampon échoue en raison d'une erreur matérielle, les systèmes de fichiers répondent différemment, mais ce comportement implique généralement de supprimer les données des pages affectées et de les marquer comme étant propres. Ainsi, une lecture des blocs qui viennent d'être écrits retournera probablement autre chose que les données écrites.

    De plus, continue-t-il dans son explication, même avant que la communauté n'entre dans la discussion, il était devenu évident que la situation n'était pas aussi simple qu'il n’y paraissait. Thomas Munro a indiqué que Linux ne se comportait pas de la sorte. OpenBSD et NetBSD peuvent également ne pas rapporter d’erreurs d’écriture dans l’espace utilisateur. Et il s’avère que la façon dont PostgreSQL traite les E/S en mémoire tampon complique considérablement l’image. Le serveur PostgreSQL s'exécute comme un ensemble de processus dont beaucoup peuvent effectuer des E/S sur les fichiers de base de données.

    Le travail d'appel de fsync() cependant, est traité dans un processus unique “checkpointer", qui consiste à maintenir le stockage sur disque dans un état cohérent pouvant être restauré à partir d'échecs. Le point de contrôle ne laisse normalement pas tous les fichiers pertinents ouverts. Il doit donc souvent ouvrir un fichier avant d'appeler fsync() dessus. C’est là que le problème se pose, souligne-t-il. Même dans les noyaux 4.13 et ultérieurs, le checkpointer ne verra aucune erreur survenue avant l’ouverture du fichier. Si quelque chose de grave se produit avant l'appel de la fonction open() du checkpointer, le paramètre fsync() retournera simplement un succès.

    Alors, comment résoudre un tel problème ?

    Avant cette question, plusieurs propositions avaient été faites pour résoudre le problème, mais ces solutions étaient toutes à court terme. Certains internautes ont pensé à adopter le mécanisme de la gestion des entrées/sorties mises en place par Google (le noyau a été instrumenté pour signaler les erreurs d'E/S via un socket netlink. Un processus dédié reçoit ces notifications et répond en conséquence) et d’autres ont proposé de définir un indicateur dans le superbloc du système de fichiers lorsqu’une erreur d’E/S se produit.

    Une autre proposition était de répondre à une erreur d'E/S en marquant le fichier lui-même (dans l'inode) comme étant dans un état d'erreur persistante. Cependant, un tel changement éloignerait davantage le comportement de Linux des mandats POSIX et soulèverait d'autres questions notamment : quand et comment cet indicateur serait-il effacé ? Donc, ce changement semble peu probable ou peu envisageable. Au FOSDEM 2019, Vondra a lui aussi, proposé deux solutions temporaires.

    La première concerne la modification du noyau de Linux et la seconde demande de déclencher PANIC au sein de PostgreSQL pour tenter d’avoir des rapports d’erreurs un peu plus précis. Lorsqu’on choisira de modifier le noyau, précise-t-il, cela nécessitera sans aucun doute beaucoup de temps, mais il pourrait payer à la fin. Ce travail permettra tout simplement de retravailler le comportement de fsync. La deuxième méthode consiste à activer les messages PANIC dans PostgreSQL pour déclencher des types d’erreurs spécifiques et de pouvoir les imprimer dans les fichiers journaux.

    Cette deuxième action nécessite que les postes exécutant le serveur PostgreSQL soient dotés d’une version supérieure ou égale à la version 4.13 du noyau. D’après certains commentaires des internautes, les systèmes de fichiers modernes sont parfois la cause du manque de performance de certaines applications. Selon eux, cela pousse des fois des développeurs d’applications à abandonner l’idée de développer leur solution pour telle ou telle plateforme et dans la plupart des cas, Linux.

    Source : FOSDEM, Vidéo de la présentation, LWN.net

    Et vous ?

    Que pensez-vous de ce problème ?
    Quelles autres solutions préconiseriez-vous pour régler le soucis ?

    Voir aussi

    Disponibilité générale de PostgreSQL 11 : un aperçu des principales fonctionnalités du SGBDRO libre

    Microsoft fait l'acquisition de Citus Data l'extension qui transforme PostgreSQL en une base de données distribuée

    Emploi développeur 2017 : les SGBD les plus demandés et les mieux payés, MySQL, MongoDB et PostgreSQL plus demandés mais MongoDB et DB2 mieux payés

    DB-Engines Ranking : PostgreSQL désigné système de gestion de base de données de l'année 2017, quels étaient vos SGBD préférés en 2017 ?

    Microsoft Azure embarque une nouvelle offre NoSQL et deux nouveaux services de bases de données pour un support natif de MySQL et PostgreSQL
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut O_SYNC
    Vu l'importance des écritures (performances et fiabilité) pour une base de données, tous les autres SGBD accèdent aux disques en Direct I/O et gèrent leur propre buffering et cache. C'est probablement la seule solution à long terme. Mais vu que PostgreSQL a toujours compté sur le cache filesystem pour simplifier le code d'accès aux données, ouvrir les fichiers en O_SYNC ne serait probablement pas viable en termes de performance sans une grosse évolution du code, et rendrait difficile la portabilité sur différents OS.
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Une des différences majeures que je montre dans mes cours est basée sur le fait que les grands SGBDR comme IBM DB2, Oracle ou MS SQL Server ont un OS interne qui gère la mémoire (donc le cache à tous les niveaux), les threads interne à l'OS - ne serait ce que pour les prioriser, les planfifier et gérer le parallélisme au sein d'une même requête - et enfin gèrent le disque de manière directe en squeezant l'OS hôte (Windows, Linux...) afin d'être certain que les écritures soient effectives et aussi pour des raisons de performances...

    Encore une fois il existe des différences très importante entre des produits "libres" quelque peu brouillon et totalement irresponsables et des outils délivrés par des éditeurs qui sont pensés à long termes par des équipes dédiées et qui engage la responsabilité de l'éditeur !

    Bref, il n'y a pas photo sur le plan des fonctionnalités, bugs et sécurité entre le libre et le commercial, même si PostGreSQL reste un excellent choix pour de petites config (bases de moins de 300 Go, moins de 100 utilisateurs simultanés, faible complexité des requêtes et transactions, et surtout pas de 24h/24 7j/7...) par rapport à MySQL farci de bugs d'à peu près et à la sécurité plus qu'incertaine !

    Pour information, certains états de la CEE, autrefois grands supporter du libre, et notamment la suède ou a été conçue MySQL, interdisent dorénavant l'usage de logiciels libre dans l'administration...
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  4. #4
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut
    Et pour info, un test que j'avais fait à l'époque pour voir les conséquences sur les IOPS en montant les filesystem en O_SYNC:
    https://blog.dbi-services.com/postgr...or-postgresql/

    Sinon, pour la petite histoire, Microsoft a fait la même erreur en portant SQL Server sur Linux, car les fichiers étaient ouverts en O_DIRECT seulement. Ils ont vite corrigé ça dès SQL Server 2017 CU8 (https://support.microsoft.com/en-us/...-2017-on-linux).
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  5. #5
    Membre confirmé
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Janvier 2011
    Messages
    203
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Janvier 2011
    Messages : 203
    Points : 507
    Points
    507
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Encore une fois il existe des différences très importante entre des produits "libres" quelque peu brouillon et totalement irresponsables et des outils délivrés par des éditeurs qui sont pensés à long termes par des équipes dédiées et qui engage la responsabilité de l'éditeur !
    Quel est le rapport entre le libre - un mouvement, une philosophie de développement - et la qualité d'un logiciel ? Encore un discours de quelqu'un qui veut enfoncer le « méchant logiciel libre »

    En plus, il existe de très bons logiciels libres (dont certains sont même développés par des entreprises - c'est pas le cas de PostegreSQL d'ailleurs ?) tout comme il existe de médiocres logiciels propriétaires. Licence ne vaut pas qualité !

    Sans oublier la quantité hallucinante de bibliothèques libres qui sont utilisées (souvent sans reconnaissance) dans les projets commerciaux (y compris de grands noms comme Apple, Microsoft, Google...).

    Citation Envoyé par SQLpro Voir le message
    Bref, il n'y a pas photo sur le plan des fonctionnalités, bugs et sécurité entre le libre et le commercial, même si PostGreSQL reste un excellent choix pour de petites config (bases de moins de 300 Go, moins de 100 utilisateurs simultanés, faible complexité des requêtes et transactions, et surtout pas de 24h/24 7j/7...) par rapport à MySQL farci de bugs d'à peu près et à la sécurité plus qu'incertaine !
    Du peu que j'en sais, PostegreSQL est considéré comme un excellent SGBD, même face aux produits commerciaux concurrents. Et je suis à peu près sûr qu'il est capable de tourner sans interruption.

    Citation Envoyé par SQLpro Voir le message
    Pour information, certains états de la CEE, autrefois grands supporter du libre, et notamment la suède ou a été conçue MySQL, interdisent dorénavant l'usage de logiciels libre dans l'administration...
    Ils interdisent ou ils privilégient plutôt des produits commerciaux ? La nuance est importante !

    Et pourquoi vouloir l'interdire de toute façon ? Car des lobbies font pression derrière ? Parce que ça « fait peur » ?

  6. #6
    Membre éprouvé

    Homme Profil pro
    Consultant ERP
    Inscrit en
    Janvier 2013
    Messages
    372
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant ERP
    Secteur : Conseil

    Informations forums :
    Inscription : Janvier 2013
    Messages : 372
    Points : 1 202
    Points
    1 202
    Par défaut De la perspective
    la délégation aux kernel et système de fichier de l'écriture bas niveau est-elle une mauvaise chose?
    Est-ce que l'argument d'autorité que les vénérables db2, mss et oracle font du directIO a une quelconque valeur?
    N'importe quelle application d'envergure tournera sur un RAID6, et probablement sur une installation électrique avec alimentation de secours.

    @SQLPro, qui a apporté de superbes contributions au site, continue de s'enfermer dans le cliché de l'initié qui vit du savoir pro-proprio,
    il ne sert à rien de répéter que postgre ne supporte pas la charge 24/7/365, c'est de moins en moins vrai voire ne l'est plus du tout.

  7. #7
    Membre du Club
    Profil pro
    Étudiant
    Inscrit en
    Septembre 2009
    Messages
    37
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Septembre 2009
    Messages : 37
    Points : 40
    Points
    40
    Par défaut
    Certains systèmes bancaires français font transiter leurs transactions via des plateformes full linux/postgres, 24/7/365 (of course), et ce depuis la 9.2.
    Donc c'est tout à fait viable et long terme

  8. #8
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par MaximeCh Voir le message
    Ensuite sur le fond, la délégation aux kernel et système de fichier de l'écriture bas niveau est-elle une mauvaise chose?
    Est-ce que l'argument d'autorité que les vénérables db2, mss et oracle font du directIO a une quelconque valeur?
    N'importe quelle application d'envergure tournera sur un RAID6, et probablement sur une installation électrique avec alimentation de secours.
    Au kernel, oui, de plus en plus. Par exemple, les I/O asynchrones sont délégués au kernel là où avant les SGBD se chargaient d'avoir plusieurs writers.
    Au système de fichier... ils sont en général développés pour des choses très différentes d'une base de donnée. Pour gérer des fichiers et des répertoires. Très différent de blocs de données.
    Effectivement les pannes disque sont plus rares aujourd'hui, mais ce n'est pas une raison pour les ignorer. Une écriture perdue, sans s'en apercevoir, peut être catastrophique: on s'apercoit de la corruption des mois après sans pouvoir le restaurer. Ou on ne s'en apercoit pas et la transaction est simplement perdue. Par contre, la rareté de ces pannes fait qu'il est acceptable de stopper l'instance en case d'erreur, là où il y a quelques années on retentait l'écriture. C'est une piste pour PostgreSQL: detecter l'erreur et sortir en panic.

    Sinon, sur open-source vs. commercial, je ne crois pas que d'avoir ignoré le problème du fsync() viennent du fait que ce soit un projet open-source. Au-contraire, la communauté réagit très bien et les développements vont assez vite. C'est plutôt le fait du démarrage universitaire du projet. Mais c'est sûr que les bases de données commerciales mettent la priorité sur la fiabilité et disponibilité.

    Citation Envoyé par SQLpro Voir le message
    Bref, il n'y a pas photo sur le plan des fonctionnalités, bugs et sécurité entre le libre et le commercial
    On a pas dit la même chose pour les systèmes d'exploitation quand Linux est arrivé? Mais maintenant, en entreprise, on ne voit plus trop de HP-UX, Solaris, AIX... Même Microsoft a porté son SGBD sur Linux. Et IBM a racheté RedHat. Linux et GNU font tourner les bases critiques dans beaucoup d'entreprise.
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  9. #9
    Membre extrêmement actif
    Profil pro
    Analyste cogniticien
    Inscrit en
    Novembre 2010
    Messages
    269
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Analyste cogniticien

    Informations forums :
    Inscription : Novembre 2010
    Messages : 269
    Points : 627
    Points
    627
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Une des différences majeures que je montre dans mes cours
    C'est un plaisir d'échanger avec vous Professeur.

    Citation Envoyé par SQLpro Voir le message
    Encore une fois il existe des différences très importante entre des produits "libres" quelque peu brouillon et totalement irresponsables
    Je suis tout à fait d'accord, PostgreSQL est un mauvais produit, très mal pensé. Et son aspect libre est probablement le défaut le plus rédhibitoire.

    Citation Envoyé par SQLpro Voir le message
    et des outils délivrés par des éditeurs qui sont pensés à long termes par des équipes dédiées et qui engage la responsabilité de l'éditeur !
    Tout à fait, il faut privilégier les grands éditeurs, garants de la qualité. Comme Oracle, qui édite l'excellent MySQL, SGBD plébiscité par les utilisateurs, et surtout pas son immonde clone libre MariaDB.

    Citation Envoyé par SQLpro Voir le message
    Pour information, certains états de la CEE, autrefois grands supporter du libre, et notamment la suède ou a été conçue MySQL, interdisent dorénavant l'usage de logiciels libre dans l'administration...
    Et je suppose que c'est grâce à vous, Professeur. Merci de nous avoir débarrassé de cette lie que représentent les logiciels libres.

  10. #10
    Futur Membre du Club
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Octobre 2015
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : Octobre 2015
    Messages : 1
    Points : 6
    Points
    6
    Par défaut Bonne blague
    Excellent,
    Jusqu'à la dernière phrase sur la Suède, j'ai cru que c'était du premier degré.
    Merci,

    Pierre

    PS: je raccroche parce que j'attends un appel du support Oracle pour essayer de récupérer une base corrompue.

  11. #11
    Membre extrêmement actif
    Homme Profil pro
    Inscrit en
    Janvier 2014
    Messages
    1 497
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Janvier 2014
    Messages : 1 497
    Points : 5 673
    Points
    5 673
    Par défaut
    Citation Envoyé par MaximeCh Voir le message
    @SQLPro, qui a apporté de superbes contributions au site, continue de s'enfermer dans le cliché de l'initié qui vit du savoir pro-proprio
    C'est pas un "cliché" c'est un business.
    Si tu es consultant SGBD c'est plus facile de faire passer la douloureuse à 900 euros par jour sur un site IT dispendieux ou ils ont payés à prix d'or des licences Oracle, Sybase ou SQL Server que sur un site de loqueteux ou ils ont installés gratuitement PosgreSQL

    Je ferais pareil à sa place, oyez oyez la populace : "Les bases de données ultra chères sont forcément bien mieux sinon elle seraient gratuite", et aussi "les bases de données ultra chères sont ultra performantes, mais vous devez embaucher un expert SGBD pour optimiser de façon adéquate des produits aussi puisant et riches en fonctionnalités" , l'hypnose de masse on sais jamais ça peu marcher...
    « L’humour est une forme d'esprit railleuse qui s'attache à souligner le caractère comique, ridicule, absurde ou insolite de certains aspects de la réalité »

  12. #12
    Membre éprouvé

    Homme Profil pro
    Consultant ERP
    Inscrit en
    Janvier 2013
    Messages
    372
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant ERP
    Secteur : Conseil

    Informations forums :
    Inscription : Janvier 2013
    Messages : 372
    Points : 1 202
    Points
    1 202
    Par défaut
    Citation Envoyé par Mingolito Voir le message
    FTFY Le conditionnement de masse, ça marche trèèès bien...
    On se corrige mais on est d'accord!

  13. #13
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut
    Dans la même idée que PostgreSQL s'appuyant sur le filesystem pour assurer la persistence avec fsync(), voici PostgreSQL s'appuyant sur glibc pour le tri des index avec corruption de données chez Trip Advisor:
    https://www.postgresql.org/message-id/flat/BA6132ED-1F6B-4A0B-AC22-81278F5AB81E%40tripadvisor.com
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  14. #14
    Membre éprouvé

    Homme Profil pro
    Consultant ERP
    Inscrit en
    Janvier 2013
    Messages
    372
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Consultant ERP
    Secteur : Conseil

    Informations forums :
    Inscription : Janvier 2013
    Messages : 372
    Points : 1 202
    Points
    1 202
    Par défaut
    Talk complémentaire du lendemain :
    https://twitter.com/PostgreSQL/statu...64861295509505

  15. #15
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2005
    Messages
    5 450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : Août 2005
    Messages : 5 450
    Points : 12 891
    Points
    12 891
    Par défaut
    Citation Envoyé par pachot Voir le message
    Sinon, sur open-source vs. commercial, je ne crois pas que d'avoir ignoré le problème du fsync() viennent du fait que ce soit un projet open-source. Au-contraire, la communauté réagit très bien et les développements vont assez vite. C'est plutôt le fait du démarrage universitaire du projet. Mais c'est sûr que les bases de données commerciales mettent la priorité sur la fiabilité et disponibilité.
    +1

    Citation Envoyé par pachot Voir le message
    On a pas dit la même chose pour les systèmes d'exploitation quand Linux est arrivé? Mais maintenant, en entreprise, on ne voit plus trop de HP-UX, Solaris, AIX... Même Microsoft a porté son SGBD sur Linux. Et IBM a racheté RedHat. Linux et GNU font tourner les bases critiques dans beaucoup d'entreprise.
    Je te rejoins aussi sur ce point .. cela a été une bonne claque pour pas mal de monde et c'est tant mieux ... Pour Microsoft l'émergence du cloud et des conteneurs (des écosystèmes très orientés Linux) ont été de gros vecteurs de décision pour le portage de SQL Server vers l'open source (et je ne vais pas m'en plaindre) ..

    ++

  16. #16
    Membre averti
    Profil pro
    Inscrit en
    Mars 2010
    Messages
    349
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 349
    Points : 439
    Points
    439
    Par défaut
    Citation Envoyé par pachot Voir le message
    Dans la même idée que PostgreSQL s'appuyant sur le filesystem pour assurer la persistence avec fsync(), voici PostgreSQL s'appuyant sur glibc pour le tri des index avec corruption de données chez Trip Advisor:
    https://www.postgresql.org/message-id/flat/BA6132ED-1F6B-4A0B-AC22-81278F5AB81E%40tripadvisor.com
    Il me semble que ce probleme a été résolu dans PG-10 en integrant ICU dans postgres directement .. https://www.2ndquadrant.com/en/blog/...postgresql-10/

  17. #17
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par champomy62 Voir le message
    Il me semble que ce probleme a été résolu dans PG-10 en integrant ICU dans postgres directement .. https://www.2ndquadrant.com/en/blog/...postgresql-10/
    Oui, la communauté PostgreSQL est très réactive sur ces problèmes.
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

Discussions similaires

  1. Réponses: 1
    Dernier message: 28/08/2017, 12h34
  2. Réponses: 0
    Dernier message: 13/09/2012, 10h51
  3. regularisation salaire "sous payer" depuis 2 ans
    Par mike17 dans le forum Paie
    Réponses: 5
    Dernier message: 25/03/2009, 19h12
  4. Fonction replace limité ? mal utilisé ?
    Par ReaseT dans le forum ASP
    Réponses: 3
    Dernier message: 11/12/2006, 12h30
  5. Réponses: 3
    Dernier message: 13/07/2006, 11h40

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo