Discussion :

[SQLpro]

Le fait qu'il y ai plus de CVE d�clar�s sur PostGresSQL ne veut pas forc�ment dire qu'il est plus vuln�rable que SQL-Server. Les sources PosGresSQL sont libre et donc consultables, il est donc plus facile d'y trouver des failles que sur un code ferm�.

Sauf que si je voulais p�ter un sql server, j'attaquerais plut�t par RDP, ou derni�rement les failles Exchange et l� on inverse compl�tement la situation.

Je pose donc deux simples questions :
1) quel est la proportion d'utilisateur PostGreSQL qui va lire le code pour voir ou se trouve le bug qu'il vient de d�couvrir ?
2) pensez vous que 20 ans soit une bonne moyenne pour d�couvrir un bug gravissime (corruption de donn�es) et 2 ans pour tenter de corriger ce m�me bug dans PostGreSQL syst�me libre et ouvert, donc selon vous plus facile � maintenir ?

R�PONSE 1, � mon avis 0,01 %

R�PONSE 2, voir : https://www.developpez.com/actu/2457...u-FOSDEM-2019/
Toujours pas corrig� � ce jour !

Bref, je vous en pr�senterais d'autres bug PG dont la correction a �t� pour le moins pittoresque !

A +

PS : suite aux prochains �pisodes...

[Christophe]

En r�ponse :

Je r�pondrais combien pour le code d'SQL-Server ? on ne sait pas, et uniquement des gens de Microsoft. Mais il me semble qu'ils fournissent un acc�s aux sources en vue d'audit.
Et avec les produits Microsoft, comme d�j� dit, tu as un combo : attaque possible par les CVE d'SQL-Server, mais aussi les autres CVE Exchange, RDS, etc.

Sur l'aspect du bug fsync PostGres, de ce que j'en ai compris, il ne s'agit pas d'un bug Postgres, la fonction du noyau retourne OK alors que les donn�es ne sont pas forc�ment encore �crite sur le disque, � cause du cache. Et quand on utilise du cache, l'�criture est d�cal�e et il y a un risque, mais on gagne en rapidit� car le processus effectuant l'�criture n'attend pas la confirmation de la r�elle �criture. C'est la m�me chose sur Windows, avec comme diff�rence que SQL-Server utilise peut-�tre ses propres drivers pour �crire sur le disque, plus efficace ou prioritaire que les drivers OS.

Et des failles non corrig�s depuis 20 ans, tu en trouve dans tous les environnements. Et si tu veux jouer �a, veux-tu que l'on parle de badtunnel, faille pr�sente de Windows 95 � Windows 10 (patch�)

[SQLpro]

... Sur l'aspect du bug fsync PostGres, de ce que j'en ai compris, il ne s'agit pas d'un bug Postgres, la fonction du noyau retourne OK alors que les donn�es ne sont pas forc�ment encore �crite sur le disque, � cause du cache. Et quand on utilise du cache, l'�criture est d�cal�e et il y a un risque, mais on gagne en rapidit� car le processus effectuant l'�criture n'attend pas la confirmation de la r�elle �criture.

Non, pas du tout... fsync est une primitive d'�criture des fichiers comme on en trouve dans la plupart des OS, et elle convient � la majorit� des fichiers qui doivent �tre �crit sur disque. Effectivement elle fait du cache. Mais le probl�me des bases de donn�es relationnelles est qu'il existe syst�matiquement au moins deux fichiers qui doivent imp�rativement �tre synchronis�s : les fichiers de donn�es d'un c�t�, le journal de transaction de l'autre. Les donn�es re�oivent une marque dite LSN (Lof Segment Number) qui est un point d'entr�e dans le journal de transaction, pour savoir ou ils en sont des donn�es r�ellement �crites. Le journal de transaction �tant compos� d'entr�e s�quentielle identifi�es par ce fameux LSN. Une m�me transaction �tant d�coup�es en diff�rents LSN au fur et � mesure de son avancement et les transactions �tant entrelac�es du fait de la concurrence.
Ce qui peut arriver de pire dans un SGBDR est la d�synchronisation de ces LSN conduisant � la corruption des donn�es. Et c'est exactement ce qui se passe avec le fsync de Linux. Dans ce cas la base de donn�e contient des donn�es qui sont corrompues car il est impossible de savoir ce qui a �t� r�ellement mis � jour et ce qui ne l'a pas �t�...

Il ne s'agit donc pas d'un bug de Linux, qui a mon sens est un OS bien fait, mais d'une mauvaise utilisation de l'OS en confiant directement les �critures de PostGreSQL � Linux par d�faut. Tous les grand �diteurs de SGBD Relationnel (donc transactionnels) le savent ! Cela a m�me �t� not� dans les articles �crit par Stonebraker (le p�re de Ingres et de PostGreSQL) dans ce livre : "The Ingres Papers: Anatomy of a Relational Database System" - Addison Weslay - 1985
Le fait pour PostGreSQL de l'avoir ignor� rel�ve que l'�quipe de d�veloppement actuelle n'est pas s�rieuse !

Quelques �l�ments � ce sujet :
https://postgresqlco.nf/doc/fr/param/fsync/
https://wiki.postgresql.org/wiki/Fsync_Errors

Apparemment ce bug vient enfin d'�tre corrig� 2 ans apr�s sa d�couverte et 22 ans apr�s que des donn�es corrompues se soient propag�e dans les bases...

A +

[Christophe]

Merci pour l'explication sur les LSN.

Par contre si je prend l'explication :

Si ce param�tre est activ�, le serveur PostgreSQL tente de s'assurer que les mises � jour sont �crites physiquement sur le disque � l'aide d'appels syst�me fsync() ou de m�thodes �quivalentes (voir wal_sync_method). Cela permet de s'assurer que le cluster de bases de donn�es peut revenir � un �tat coh�rent apr�s une panne mat�rielle ou du syst�me d'exploitation.
Bien que d�sactiver fsync am�liore fr�quemment les performances, cela peut avoir pour cons�quence une corruption des donn�es non r�cup�rables dans le cas d'une perte de courant ou d'un crash du syst�me. Donc, il est seulement conseill� de d�sactiver fsync si vous pouvez facilement recr�er la base de donn�es compl�te � partir de donn�es externes.

Je ne comprend pas d�o� vient le probl�me avec PostGres

As of this PostgreSQL 12 commit, PostgreSQL will now PANIC on fsync() failure.

c'est donc �a la correction ?

Si le param�tre de contr�le fsync est activ�, et que le fsync �chouait la base continuait � fonctionner (donc dans un �tat potentiellement instable) c'est �a ?

Il ne s'agit donc pas d'un bug de Linux, qui a mon sens est un OS bien fait, mais d'une mauvaise utilisation de l'OS en confiant directement les �critures de PostGreSQL � Linux par d�faut.

L� je comprend : d�faut de conception.

extrait de la discussion sur la mauvaise utilisation fsync avec 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).

Ce qui me fait dire que c'est un peu plus compliqu� que �a. Si m�me Microsoft a fait de cette fa�on au d�part.
Apr�s il est plus facile d'optimiser les �critures IO directes quand on fait � la fois le SGBD, l'OS, et le filesystem.

[Invit�]

Bonjour,

Non, pas du tout... fsync est une primitive d'�criture des fichiers comme on en trouve dans la plupart des OS, et elle convient � la majorit� des fichiers qui doivent �tre �crit sur disque. Effectivement elle fait du cache. Mais le probl�me des bases de donn�es relationnelles est qu'il existe syst�matiquement au moins deux fichiers qui doivent imp�rativement �tre synchronis�s : les fichiers de donn�es d'un c�t�, le journal de transaction de l'autre. Les donn�es re�oivent une marque dite LSN (Lof Segment Number) qui est un point d'entr�e dans le journal de transaction, pour savoir ou ils en sont des donn�es r�ellement �crites. Le journal de transaction �tant compos� d'entr�e s�quentielle identifi�es par ce fameux LSN. Une m�me transaction �tant d�coup�es en diff�rents LSN au fur et � mesure de son avancement et les transactions �tant entrelac�es du fait de la concurrence.
Ce qui peut arriver de pire dans un SGBDR est la d�synchronisation de ces LSN conduisant � la corruption des donn�es. Et c'est exactement ce qui se passe avec le fsync de Linux. Dans ce cas la base de donn�e contient des donn�es sont corrompues car il est impossible de savoir ce qui a �t� r�ellement mis � jour et ce qui ne l'a pas �t�...

Il ne s'agit donc pas d'un bug de Linux, qui a mon sens est un OS bien fait, mais d'une mauvaise utilisation de l'OS en confiant directement les �critures de PostGreSQL � Linux par d�faut. Tous les grand �diteurs de SGBD Relationnel (donc transactionnels) le savent ! Cela a m�me �t� not� dans les articles �crit par Stonebarker (le p�re de Ingres et de PostGreSQL) dans ce livre : "The Ingres Papers: Anatomy of a Relational Database System" - Addison Weslay - 1985
Le fait pour PostGreSQL de l'avoir ignor� rel�ve que l'�quipe de d�veloppement actuelle n'est pas s�rieuse !

Quelques �l�ments � ce sujet :
https://postgresqlco.nf/doc/fr/param/fsync/
https://wiki.postgresql.org/wiki/Fsync_Errors

Apparemment ce bug vient enfin d'�tre corrig� 2 ans apr�s sa d�couverte et 22 ans apr�s sue des donn�es corrompues se soient propag�e dans les bases...

A +

Merci pour ces infos. Je comprend mieux que PostGre soit d�cri� du coup

[SQLpro]

Non, pas du tout... fsync est une primitive d'�criture des fichiers comme on en trouve dans la plupart des OS, et elle convient � la majorit� des fichiers qui doivent �tre �crit sur disque. Effectivement elle fait du cache. Mais le probl�me des bases de donn�es relationnelles est qu'il existe syst�matiquement au moins deux fichiers qui doivent imp�rativement �tre synchronis�s : les fichiers de donn�es d'un c�t�, le journal de transaction de l'autre. Les donn�es re�oivent une marque dite LSN (Lof Segment Number) qui est un point d'entr�e dans le journal de transaction, pour savoir ou ils en sont des donn�es r�ellement �crites. Le journal de transaction �tant compos� d'entr�e s�quentielle identifi�es par ce fameux LSN. Une m�me transaction �tant d�coup�es en diff�rents LSN au fur et � mesure de son avancement et les transactions �tant entrelac�es du fait de la concurrence.
Ce qui peut arriver de pire dans un SGBDR est la d�synchronisation de ces LSN conduisant � la corruption des donn�es. Et c'est exactement ce qui se passe avec le fsync de Linux. Dans ce cas la base de donn�e contient des donn�es sont corrompues car il est impossible de savoir ce qui a �t� r�ellement mis � jour et ce qui ne l'a pas �t�...

Il ne s'agit donc pas d'un bug de Linux, qui a mon sens est un OS bien fait, mais d'une mauvaise utilisation de l'OS en confiant directement les �critures de PostGreSQL � Linux par d�faut. Tous les grand �diteurs de SGBD Relationnel (donc transactionnels) le savent ! Cela a m�me �t� not� dans les articles �crit par Stonebarker (le p�re de Ingres et de PostGreSQL) dans ce livre : "The Ingres Papers: Anatomy of a Relational Database System" - Addison Weslay - 1985
Le fait pour PostGreSQL de l'avoir ignor� rel�ve que l'�quipe de d�veloppement actuelle n'est pas s�rieuse !

Quelques �l�ments � ce sujet :
https://postgresqlco.nf/doc/fr/param/fsync/
https://wiki.postgresql.org/wiki/Fsync_Errors

Apparemment ce bug vient enfin d'�tre corrig� 2 ans apr�s sa d�couverte et 22 ans apr�s que des donn�es corrompues se soient propag�e dans les bases...

A +

[SQLpro]

...
Je voulais ajouter mon grain de sel � la discussion car on parle de pur performance mais il faut bien comprendre (pour ceux qui vont me lire) que �a n'a aucune valeur de qualit� pour le choix d'une base de donn�e.

J'ai lu beaucoup de conneries dans ma vie, mais des aussi grosses... Rarement !

En quoi le fait d'�tre plus performant serait moins bon ?

Le fait d'�tre plus performant �conomise des ressources et permet de faire des �conomies � tous les niveaux : �lectricit�, refroidissement, ing�nieries, maintenance... Cela s'appelle de l'�cologie.... Mais visiblement ce n'est pas le fort des informaticiens, qui, il n'y a pas si longtemps, pr�f�rait le langage Python le pire de tous les langages en termes de consommation d'�nergie....

... je voudrais signaler aux d�veloppeur.ses qui cherchent une base de donn�e de consid�rer la performance comme tertiaire � votre choix, si vous prenez une bdd uniquement sur ces performances vous allez planter votre projet c'est garanti.

Un argument aussi stupide et aucunement �tay� m�ritait une exergue !

A +