sql >> Database teknologi >  >> RDS >> PostgreSQL

Arbejder hen imod Postgres-XL 9.5

Det har været nogle travle måneder, da vi arbejder på at fusionere Postgres-XL med den seneste og bedste udgivelse af PostgreSQL. Postgres-XL er en open source fork af PostgreSQL, der giver en skalerbar platform til OLTP og Business Intelligence. Den nuværende udgivelse af Postgres-XL er baseret på PostgreSQL 9.2, så den mangler alle de forbedringer, der er lavet til PostgreSQL i løbet af de sidste tre år.

2ndQuadrant og andre virksomheder arbejder på at bringe distribueret skalerbarhed ind i PostgreSQL-kernen samt at bygge værktøjer og udvidelser uden for kernen. Som en del af det har Postgres-XL en række funktioner, som vi gerne vil bringe tilbage til kerne PostgreSQL, så 2ndQuadrant har taget opgaven med at opdatere Postgres-XL-kodebasen til den seneste PostgreSQL-udgivelse som det første skridt. Efter mere end 3 måneders arbejde er PostgreSQL 9.5 stadig i alfastadiet, så vi ville gerne give en statusrapport om, hvordan arbejdet forløber. Jeg har også brug for at sige de magiske ord:Dette igangværende arbejde med Postgres-XL er en del af AXLE-projektet, finansieret af EU under tilskudsaftale 318633.

Forberedelse til sammenlægningen

Da PostgreSQL og Postgres-XL begge bruger GIT som kildekontrolsystem, gør det fletningsprocessen meget enklere, da GIT giver mange værktøjer til at hjælpe processen. Men så snart vi prøvede sammenlægningen, stod vi over for den første forhindring.

Vi indså, at det nuværende Postgres-XL-lager er baseret på en ældre mindre 9.2-udgivelse af PostgreSQL. Det betyder, at der var commits og ændringer i Postgres-XL-mastergrenen, som enten aldrig blev foretaget til PostgreSQL's master-gren eller havde forskellige commit-id'er. Så fusion med PostgreSQL-mastergrenen gav mange flere konflikter, end hvad vi andre ville have forventet. Så den første opgave, vi skulle udføre, var at rebasere Postgres-XL 9.2-lageret på et senere commit-punkt. Dette krævede naturligvis omhyggelig betræden, så man sikrede sig, at intet går i stykker under processen. Da vi havde lavet den grundlæggende rebase, slog vi også alle Postgres-XL fejlrettelser og forbedringer sammen, skabte en Postgres-XL 9.2 stabil gren og fusionerede 9.2 grenen med den seneste tilgængelige PostgreSQL 9.2 mindre udgivelse.

Udfordringer under fusionen

Selve fusionen med PostgreSQL-mastergrenen var heller ikke en nem opgave. Bemærk, at vi hoppede over 3 store udgivelser af PostgreSQL, som næsten tegnede sig for 3 års udviklingsarbejde. Heldigvis er git-mergetool meget praktisk til så store fusioner. Du kan bruge din foretrukne editor (vimdiff i vores tilfælde) til pænt at se flettekonflikterne og løse dem. Mens nogle af konflikterne er ligetil og kræver mindre justeringer, kræver mange omhyggelig læsning og forståelse af koden. Selvom det ikke er trivielt at understøtte alle nye funktioner, forsøgte vi at bevare så meget som muligt, og vi har haft ret stor succes.

Den anden store udfordring var at sammenlægge dokumentationsændringer. Da Postgres-XL-projektet havde oprettet en kopi af den eksisterende SGML-dokumentation, gav GIT-fusionen med mastergrenen ingen opdateringer til kopien. Denne krævede manuel fletning. For at sikre, at dette ikke er påkrævet igen i fremtidige sammenlægninger, foretager vi nu dokumentationsændringerne på plads.

Hvad er det næste?

Der er mange ting, der skal afsluttes, før vi kan frigive Postgres-XL 9.5 til offentligheden:

  1. Forbedre regressionstestdækningen for Postgres-XL
  2. Ret fejl, og tilføj understøttelse af nye funktioner
  3. Udfør systematiske præstationstests og tuning
  4. Opret Postgres-XL 9.5 filial og flet med den seneste PostgreSQL 9.5 stabil filial

Vi er endnu ikke klar til gennemgang af Postgres-XL, men vi forventer, at Postgres-XL 9.5 Beta er klar omkring samme tid som PostgreSQL 9.5 Beta.

Se efter mit næste blogindlæg om cirka en måned til den næste opdatering.


  1. Hvordan fjerner man en unik begrænsning i SQL?

  2. MySQL Tutorial – Håndtering af MySQL-serverlogfiler:Roter, komprimer, bevar og slet

  3. Brug strtotime til datoer før 1970

  4. Oracle Sequence-værdier er ikke bestilt