Postgres réécrit en Rust, passe désormais 100 % des tests de régression Postgres

 (github.com/malisper)
1 points par GN⁺ 5 시간 전 | 1 commentaires | Partager sur WhatsApp
  • pgrust est un projet de réécriture de Postgres en Rust visant la compatibilité avec Postgres 18.3, et il correspond à la sortie attendue de Postgres sur plus de 46 000 requêtes de régression
  • Il offre une compatibilité disque permettant de démarrer à partir d’un répertoire de données Postgres 18.3 existant, et utilise les vrais tests Postgres comme référence comportementale
  • Il n’est actuellement pas prêt pour la production, n’a pas encore été optimisé en termes de performances, et n’est généralement pas compatible avec les extensions Postgres existantes ni avec les extensions de langages procéduraux comme PL/Python, PL/Perl et PL/Tcl
  • Il peut être essayé via une démo WebAssembly et avec l’image Docker malisper/pgrust:v0.1 ; latest pointe actuellement vers la même release, mais l’image de release figée est v0.1
  • La feuille de route comprend une architecture interne multithreadée de Postgres, un pooling de connexions intégré, des améliorations pour les charges de travail centrées sur JSON, des expérimentations de stockage sans vacuum, et des garde-fous à l’exécution pour le SQL généré par IA

Objectifs et compatibilité de pgrust

  • pgrust est un projet de réécriture de Postgres en Rust
  • La cible est Postgres 18.3, et il correspond à la sortie attendue de Postgres sur plus de 46 000 requêtes de régression
  • Il fournit une compatibilité disque permettant de démarrer depuis un répertoire de données Postgres 18.3 existant
  • Le projet vise à rendre Postgres plus facile à modifier en interne
    • Le comportement reste conforme à celui de Postgres
    • Les vrais tests Postgres servent de référence
    • Rust et la programmation assistée par IA sont utilisés pour explorer des modifications plus profondes du serveur

État actuel et limites

  • pgrust n’est pas encore prêt pour la production
  • Il n’a pas encore été optimisé en performances
  • Les extensions Postgres existantes et les extensions de langages procéduraux ne sont généralement pas encore compatibles
    • PL/Python
    • PL/Perl
    • PL/Tcl
  • Certains modules contrib fournis ont déjà été portés, et davantage de compatibilité pourrait être possible avec le temps

Comment l’exécuter

  • La démo WebAssembly peut être essayée sur https://pgrust.com
  • L’exécution via Docker utilise l’image malisper/pgrust:v0.1
    • Elle utilise le client psql présent dans l’image
    • malisper/pgrust:latest pointe actuellement vers la même release
    • L’image de release figée est v0.1
docker run -d --name pgrust -e POSTGRES_PASSWORD=secret malisper/pgrust:v0.1 && until docker exec -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U postgres -c '\q' >/dev/null 2>&1; do sleep 1; done && docker exec -it -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U postgres; docker rm -f pgrust

Compilation depuis les sources et exécution

  • Sur macOS, icu4c, openssl@3 et libpq sont nécessaires
brew install icu4c openssl@3 libpq

export LIBRARY_PATH="$(brew --prefix openssl@3)/lib:${LIBRARY_PATH:-}"
export PKG_CONFIG_PATH="$(brew --prefix openssl@3)/lib/pkgconfig:$(brew --prefix icu4c)/lib/pkgconfig:${PKG_CONFIG_PATH:-}"
export PATH="$(brew --prefix libpq)/bin:$PATH"
  • Sur Debian/Ubuntu, il faut installer les outils de build ainsi que ICU, OpenSSL, LDAP, PAM et le client Postgres 18
sudo apt-get update
sudo apt-get install -y build-essential pkg-config libicu-dev libssl-dev libldap2-dev libpam0g-dev postgresql-client-18
  • La compilation se fait avec cargo build en indiquant le répertoire partagé du Postgres 18.3 embarqué
PGRUST_PGSHAREDIR="$PWD/vendor/postgres-18.3/share" \
cargo build --release --locked --bin postgres
  • Le répertoire de données est créé avec --initdb de pgrust
target/release/postgres --initdb \
  -D /tmp/pgrust-data \
  -L "$PWD/vendor/postgres-18.3/share" \
  --no-locale \
  --encoding UTF8 \
  -U postgres
  • Lors de l’exécution, des réglages liés à la pile et des paramètres d’E/S synchrones sont utilisés
ulimit -s 65520

RUST_MIN_STACK=33554432 target/release/postgres \
  -D /tmp/pgrust-data \
  -F \
  -c listen_addresses= \
  -k /tmp \
  -p 5432 \
  -c io_method=sync \
  -c max_stack_depth=60000

Tests de régression et résultats de validation

  • Les tests de régression Postgres s’exécutent avec scripts/run-regression
PGRUST_BIN="$PWD/target/release/postgres" \
scripts/run-regression
  • Le lanceur de tests utilise le propre --initdb de pgrust et les fichiers de test Postgres 18.3 inclus dans le dépôt
  • Le client psql de Postgres 18 doit être présent dans le PATH
    • S’il se trouve ailleurs, définir PGRUST_PSQL=/path/to/psql
  • Le résultat de release validé est que pgrust correspond à la sortie attendue de Postgres sur plus de 46 000 requêtes de régression

Feuille de route et historique du projet

  • La feuille de route comprend les éléments suivants

    • Architecture interne multithreadée de Postgres

      • Pooling de connexions intégré
      • Amélioration de la prise en charge des charges de travail centrées sur JSON
      • Workflows rapides de fork et de branchement
      • Expérimentations de stockage incluant une conception sans vacuum
      • Garde-fous à l’exécution pour les requêtes erronées et le SQL généré par IA
      • Réduction des basculements soudains vers de mauvais plans d’exécution
      • Le dépôt actuel contient une implémentation plus récente de pgrust ayant atteint le jalon des tests de régression
      • L’implémentation publique précédente est archivée dans archive/pre-fabled-2026-06-23
      • Liens de contexte associés
      • Original pgrust launch
      • 67% regression update
      • Four Horsemen roadmap
      • La licence est AGPL-3.0

À lire aussi

1 commentaires

 
GN⁺ 5 시간 전
Commentaires sur Hacker News

  • Je suis l’auteur original. Je ne m’attendais pas à voir ça ici. En résumé, j’expérimente pour voir si on peut construire un meilleur Postgres avec des LLM, et comme Postgres a 30 ans, j’estime qu’on a aussi beaucoup appris sur les bases de données pendant ce temps.
    Une bonne partie des techniques utiles pour une réécriture le sont aussi pour une refonte. La nouvelle version de pgrust, pas encore publiée, passe actuellement à 100 % les tests de régression de Postgres, implémente un modèle un thread par connexion au lieu du modèle un processus par connexion de Postgres, et elle est 50 % plus rapide que Postgres sur des charges transactionnelles, et environ 300 fois plus rapide sur des charges analytiques.
    Pour l’instant, elle est 2 fois plus lente que ClickHouse sur clickbench, mais je pense qu’elle peut devenir plus rapide que ClickHouse. Je répondrai aux questions.

    • Le thread par connexion est presque toujours le bon choix du point de vue des performances, mais le fait que Postgres ait choisi le processus par connexion permet de charger librement des extensions douteuses. Dans le pire des cas, seul ce processus plante, pas toute la base de données. Il serait bien d’avoir un compromis où une faute de segmentation dans une extension ne tue qu’une partie des connexions, et non l’ensemble.
    • L’amélioration de 50 % en OLTP me semble un peu suspecte. Je ne veux pas tirer à boulets rouges sans éléments, et moi aussi je fais souvent des affirmations basées sur des benchmarks, mais même en sachant qu’un benchmark standard a été utilisé, il y a quelque chose qui me chiffonne.
      Il est possible qu’un compromis rendant le tout inutilisable en production ait cassé la MVCC quelque part. J’ai bien vu que les tests de régression passent. Est-ce que fsync est activé ? De ce que je sais, les tests de régression détectent mal les mauvais schémas d’entrées/sorties. Cela dit, le projet a l’air intéressant.
    • Je suis curieux de connaître le vrai parcours et le niveau d’expertise sur Postgres et les bases de données en général. En fin de compte, j’aimerais savoir si la personne sait exactement ce qu’elle fait, ou s’il y a une énorme mine antipersonnel cachée qu’elle n’a pas vue.
    • On dirait que c’était plutôt une expérimentation qu’un lancement produit, mais que quelqu’un l’a poussé sous les projecteurs de HN. Je me demande si c’est une expérience pour voir jusqu’où on peut aller avec du code généré par LLM, ou plutôt une expérience où l’on construit d’abord, puis on mesure quelle part du code écrit par le LLM on peut réellement accepter.
    • Dire que c’est environ 300 fois plus rapide que Postgres sur des charges analytiques, tout en étant 2 fois plus lent que ClickHouse, signifie-t-il que les données sont stockées dans un format orienté colonnes ? Ou bien qu’on utilise à la fois du row-oriented et du column-oriented ?
      Je travaille sur quelque chose de similaire mais différent, δx. C’est une extension Postgres qui stocke des données compressées orientées colonnes à l’intérieur de tables Postgres ordinaires, ce qui permet à la réplication, à la reprise après incident, à pg_dump, etc. de continuer à fonctionner tels quels : https://github.com/xataio/deltax
      Pour l’instant, sur un nœud unique, c’est 30 à 40 % plus lent que ClickHouse. Une PR pour l’ajouter à clickbench vient d’être acceptée, donc on peut voir la comparaison ici : https://benchmark.clickhouse.com/#system=+liH|_etx|gQ|saB&ty...

  • J’ai du mal à comprendre ce genre de réécriture. En général, c’est porté par une seule personne, ce qui en fait facilement un point de défaillance unique, et c’est produit en très peu de temps, donc difficile d’y voir la discipline nécessaire pour construire un projet de manière durable.
    À moyen et long terme, ça semble aussi peu probable à maintenir. Les gens qui voudraient contribuer doivent eux aussi payer le coût en tokens. Comme il devient de plus en plus difficile de maintenir ce genre de projet sans IA, est-ce que quelqu’un voudrait vraiment mettre ça en production ? Ça ne me paraît pas très cohérent.

    • Ce n’est pas qu’une simple réécriture, il y a aussi des améliorations. Pour m’amuser, j’ai fait quelque chose d’assez proche, parce que je voulais voir si on pouvait améliorer un vieux design, notamment sur des points où les gens côté PostgreSQL disaient qu’« on ne peut pas faire autrement ». En réalité, on peut faire autrement.
      Je ne le mettrais pas en production, mais j’ai énormément appris sur les entrailles des bases de données. Même à l’ère des LLM, pour garder mon cerveau occupé, j’implémente aussi des fonctionnalités de base de données dans notre base de production sans LLM. En ce moment je galère avec Flexible Paxos, et je finirai probablement par continuer à utiliser le bon vieux Raft, stable et simple, mais c’est intéressant malgré tout.
    • J’y vois une preuve de concept intéressante. Il ne s’agit pas seulement de réécrire PostgreSQL en Rust, mais aussi de tester la viabilité des dépendances choisies, du changement de modèle de threading et d’autres changements d’architecture.
      Les LLM sont extrêmement forts pour produire des prototypes très vite, et un prototype fonctionnel peut mettre fin à beaucoup de spéculations. Sans l’appui de l’équipe d’origine, ou d’un effectif comparable, et sans explication crédible montrant que la qualité du code et la maintenabilité de l’original ont été égalées ou dépassées, je pense que je n’utiliserais pas une telle réécriture d’un projet aussi massif.
      Plus généralement, je pense que faire du blanchiment de licence avec des LLM est difficile à défendre juridiquement comme moralement. Cela dit, dans ce cas précis c’est différent, puisqu’une licence plus restrictive a été choisie. Je ne suis pas juriste, mais je comprends qu’il est légal de télécharger PostgreSQL, faire un s/MIT/AGPL/, puis le redistribuer. La version originale sous licence MIT reste disponible telle quelle, donc sans nouvelles fonctionnalités vraiment convaincantes, il n’y a pas de raison particulière de préférer cette version.
    • Ce n’est pas exactement pareil, mais à partir d’un jeu de plans existants, reconstruire un modèle 3D est beaucoup plus rapide et plus facile que de repartir de zéro. Beaucoup de décisions ont déjà été prises.
    • Pour un projet de la taille de Postgres, le maintenir sans IA est en pratique presque impossible. Si je me souviens bien, Postgres fait plus d’un million de lignes.

  • La meilleure façon de tester ça serait probablement de mettre un proxy comme PgBouncer devant une base de données de production très sollicitée, puis de dupliquer les requêtes à la fois vers le Postgres existant et vers la version Rust.
    On pourrait alors comparer la sortie et les performances sous charge réelle. Après l’avoir laissé tourner un moment, on pourrait aussi comparer les tables une par une avec l’instance Postgres classique.

  • Comment faut-il examiner un code comme celui-ci ? En général, on parcourt l’historique des commits pour voir ce que les gens ont fait et comment, mais quand un LLM produit 7 101 commits en moins d’un mois, c’est impossible
    Même une seule journée en fait déjà beaucoup trop [1]. De toute façon, le contenu des commits n’apprend pas forcément grand-chose. Je me demande aussi s’il existe un moyen simple d’aller au premier commit d’un dépôt sur GitHub. Explorer l’historique des commits me paraît assez fastidieux
    [1] - https://github.com/malisper/pgrust/commits/main/?since=2026-...

    • Je travaille sur pgrust avec malisper. Sur un projet comme celui-ci, l’attention va sans doute se déplacer de la revue de chaque commit vers la revue des tests et du fuzzing
      Il faut aller bien au-delà des tests de régression, d’isolation et de panne de Postgres. Article connexe de danluu : https://danluu.com/ai-coding/
    • Le github cli a une commande pour interroger les commits avec des drapeaux de tri croissant/décroissant : https://cli.github.com/manual/gh_search_commits
      La documentation de la syntaxe comme before x date est ici : https://docs.github.com/en/search-github/searching-on-github...
      Il existe aussi une page de recherche avancée, mais elle ne prend pas en charge les commits avec filtre par date : https://github.com/search/advanced
      On peut aussi faire une recherche dichotomique sur les dates dans le widget de recherche, et voici le premier jour où il y a eu des commits : https://github.com/malisper/pgrust/commits/main/?since=2026-...
      Premier commit : https://github.com/malisper/pgrust/commit/22113dc36b02973060...
    • Plus généralement, sans historique des prompts et sans possibilité de relancer directement la « compilation » du LLM, il est ambigu de dire que c’est de l’open source. On a presque l’impression d’être plus proche d’un projet en « source available », où le code peut être lu mais où le système de build n’est pas accessible
      À l’inverse, on n’a jamais eu accès non plus au raisonnement interne d’un développeur humain, en dehors des messages de commit ; donc dire qu’un prompt secret équivaut à du code source privé n’est peut-être pas tout à fait la même chose
    • Pour aller facilement au premier commit sur GitHub, on peut utiliser la syntaxe github.com/user/repo/commits/?after=last_commit_hash+number_of_commits-2
      L’idée est de faire -1, -1 à cause du commit le plus récent et du tout dernier commit
      Exemple : https://github.com/malisper/pgrust/commits/?after=3646a73515...
    • Je ne fais pas de revue. Il faut simplement croire que la réussite des tests de régression signifie une compatibilité totale avec l’original

  • C’est impressionnant, mais cela change aussi la licence PostgreSQL [0] en AGPL [1]
    J’aime l’AGPL et je pense que c’est l’une des meilleures vraies licences libres open source, mais je me demande si c’est compatible. S’il s’agit d’une réécriture à partir du code source original, ne devrait-on pas garder la licence d’origine ? C’est ce qu’il me semble. On a déjà vu une tendance à réécrire des logiciels open source sous des licences plus restrictives, comme les coretools en Rust. Le fait d’avoir choisi l’AGPL paraît bien plus éthique, mais n’aurait-il pas été plus sûr de ne rien changer du tout ?
    [0] https://www.postgresql.org/about/licence/
    [1] https://github.com/malisper/pgrust?tab=AGPL-3.0-1-ov-file

    • Je pense que tu comprends le sens de la restriction à l’envers. uutils coreutils, sous licence MIT, est moins restrictif que GNU coreutils, sous GPL, et l’AGPL est plus restrictive que la licence PostgreSQL
      Distribuer une réécriture sous une licence plus restrictive ne viole pas la licence PostgreSQL. Si les licences de type MIT sont moins restrictives que la GPL ou l’AGPL, c’est précisément parce qu’elles autorisent une relicenciation plus restrictive
    • Si la licence ne te plaît pas, il suffit de demander à un LLM de le « porter » pendant quelques jours puis d’y mettre la licence que tu veux. Apparemment, c’est comme ça que ça se passe aujourd’hui
    • La licence PostgreSQL est une variante de la licence BSD, donc compatible avec la (A)GPL
      On peut le comprendre ainsi : on crée un projet (A)GPL vide, puis on y importe la base de code BSD amont. Les fichiers amont d’origine restent sous leur licence permissive initiale, mais l’ensemble du projet est régi par la (A)GPL, y compris les obligations d’attribution de la licence amont. La GPL autorise ce type d’exigence. On peut ensuite ajouter son propre code sous AGPL et distribuer l’œuvre combinée sous AGPL
      Si quelqu’un reprend uniquement les parties de code que vous avez écrites, il n’a qu’à respecter l’AGPL. Mais s’il inclut aussi les sources amont, il doit continuer à respecter les obligations d’attribution de la licence amont
    • La licence Postgres est déjà entièrement compatible avec l’AGPL. BSD/MIT est plus permissif

  • Il y a 2 664 unsafe { et 1 835 unsafe fn. Ce n’est pas du tout entièrement sûr. Ça ne ressemble pas à une réécriture qui comprend réellement ce qui se passe ni comment repenser l’architecture pour tirer parti des avantages de Rust
    Ça ressemble plutôt à une conversion générée par IA qui utilise massivement des pointeurs bruts

    • La plupart des unsafe sont confinés dans le parseur généré en faisant tourner c2rust sur le parseur Postgres. Le parseur Postgres lui-même est aussi généré à partir de yacc/bison, donc ils ont choisi un portage mécanique plutôt qu’un passage vers un Rust idiomatique
      S’il y a des unsafe que vous jugez particulièrement graves, ce serait bien de les signaler
    • Dans tous les projets LLM écrits en Rust, je mets unsafe=deny. Je ne comprends pas pourquoi tout le monde n’anticipe pas ce genre de réaction
    • Il suffit de copier-coller ce commentaire de revue tel quel dans le prompt. Dans quelques heures, ce sera sans doute « corrigé ! »

  • Il faut sans doute distinguer clairement une réécriture d’une réécriture par IA

    • Par exemple, la réécriture de TypeScript en Go a été faite en grande partie par des humains, et il a fallu un an avant qu’elle soit rendue publique. C’est comme ça qu’on fait des réécritures logicielles auxquelles les gens peuvent faire confiance
    • Ça n’a pas l’air si simple. Presque 100 % des projets nouveaux et ambitieux vont probablement utiliser l’IA dans une certaine mesure. Je connais quelques projets qui ont une politique strictement sans IA, comme Zig, mais ça reste une toute petite minorité
      Dans ce cas, à partir de quel niveau d’usage de l’IA peut-on parler de « réécriture par IA » ?
    • La réécriture semble être un domaine où les LLM conviennent mieux que les humains. C’est en grande partie du travail répétitif simple, et les LLM sont bien adaptés aux tâches de traduction. Si je me souviens bien, l’architecture des transformers a d’ailleurs été inventée à l’origine pour la traduction
    • Une réécriture humaine sans maintenance, ce n’est qu’un projet hobby. Une réécriture par IA, je ne vois même pas à quoi ça sert de brûler des tokens pour ça
    • À ce stade, c’est devenu simplement une étape de build

  • On voit souvent ces projets de réécriture affirmer qu’ils fonctionnent grâce aux tests. Mais ce qui rend des logiciels comme Postgres ou SQLite dignes de confiance, ce ne sont pas les tests en eux-mêmes, mais plutôt les cicatrices accumulées en production
    La fiabilité se construit au fil des années d’exploitation réelle

    • La majeure partie des énormes suites de tests est précisément constituée de ces cicatrices de production. À chaque bug ou régression, on écrit un test qui vérifie le bon comportement
      SQLite en est un bon exemple. L’immense batterie de tests privée de SQLite est souvent citée comme un élément qui rend les forks difficiles. Turso y est parvenu, mais garantir un niveau de sérieux équivalent demande une entreprise. Et bien sûr, il faut aussi des années de production
    • Ce n’est pas un jugement sur cette réécriture en particulier, mais les tests sont une spécification du bon fonctionnement du logiciel. Si un comportement n’est couvert par aucun test automatisé, on ne peut pas affirmer qu’un changement donné ne le casse pas
      Dire que quelque chose fonctionne en réutilisant la suite de tests existante sans la modifier est tout à fait raisonnable. Plus le projet est gros, plus c’est vrai à mon avis. Les cicatrices issues de la production doivent être documentées et protégées dans la suite de tests, sinon ces enseignements se perdent
      SQLite est connu pour son énorme suite de tests et son fuzzing intensif. Il y a 590 fois plus de code et de scripts de test que de code normal. Source : https://sqlite.org/testing.html
    • Dans ce cas, il faut rendre ce niveau de fiabilité facile à réinjecter en amont
      À l’heure actuelle, la chose la plus utile à faire avec ce type de version convertie par LLM, si elle passe tous les tests d’origine, c’est d’exécuter dessus la suite de tests de mon application pour repérer les lacunes de couverture de tests dans l’original
      Si la version convertie plante ou présente un dysfonctionnement observable, cela signifie qu’il manquait un test de régression dans le vrai projet. Si ce type de projet de conversion pouvait être exécuté facilement et en toute sécurité comme une ligne de plus dans une matrice habituelle de tests d’intégration, l’amont pourrait bien mieux éviter de casser accidentellement quelque chose dans de futures mises à jour
    • D’accord. Je suis aussi d’accord avec le commentaire voisin disant qu’on écrit un test qui vérifie le bon comportement chaque fois qu’un bug ou une régression apparaît
      Cela dit, ce qu’on ne voit pas dans ce genre de réécriture, c’est comment on gère les nouveaux bugs introduits par la réécriture elle-même. Au final, il faut bien qu’elle soit confrontée à des scénarios réels, non ?
    • Il existe aussi une autre façon de valider une réécriture. Il suffit de faire tourner pgrust et postgres côte à côte et de comparer les sorties
      Si vous connaissez des cas limites, faites-les tourner aussi ; sinon, utilisez un fuzzer ou des outils d’automatisation pour trouver des entrées intéressantes. Si vous trouvez un écart, cette paire entrée/sortie devient alors un cas de test. Je ne sais pas si un tel outil existe, mais si oui, il suffit de le donner à Claude pour l’intégrer dans la boucle de développement

  • La démo WebAssembly qui s’exécute dans le navigateur est vraiment propre : https://pgrust.com

  • Je ne sais pas pourquoi il y a autant de négativité. Je trouve que ce genre de projet est intéressant à des fins d’apprentissage et pour explorer de nouvelles approches. Où est le problème ?

    • La raison est peut-être la suivante : il profite d’une marque déjà établie, Postgres + Rust, sans utilité pratique ni réel progrès, et avec un manque de crédibilité.
      En particulier, quand un nom à fort pouvoir de signalisation comme Postgres figure dans le titre et est mis en avant, mais que c’est manifestement peu pratique à court et long terme, pour des raisons d’utilité, de confiance sociale ou d’effet de réseau, cela semble facilement susciter du rejet
    • C’est inconfortable de voir des décennies de travail être copiées aussi facilement
    • Je me demande exactement ce qu’on apprend en demandant à un LLM de faire une réécriture
    • Les gens semblent se sentir menacés en voyant un LLM réussir quelque chose qu’ils considéraient comme nécessitant leurs propres compétences et leur talent.
      C’est compréhensible, mais ce n’est ni productif ni particulièrement rationnel comme sentiment négatif. Ce fil est rempli de messages qui veulent affirmer que cela ne peut pas être une bonne chose, que cela ne devrait pas l’être, et que cela finira forcément en catastrophe. Pourtant, le fait que cet objet ait réussi des dizaines de milliers de tests sophistiqués accumulés pendant des décennies suggère plutôt l’inverse. C’est difficile à réfuter.
      Bien sûr, il est très probable que de nouveaux problèmes apparaissent, mais cela reste une réussite impressionnante
    • La qualité m’inquiète. Même en parcourant rapidement le code, il a l’air idiot. À moins que je ne sois simplement incapable d’en percevoir le génie.
      https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...
      https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...