Tips og tricks til at navigere i PostgreSQL-fællesskabet

Denne blog handler om PostgreSQL-fællesskabet, hvordan det fungerer, og hvordan man bedst navigerer i det. Bemærk, at dette kun er en oversigt ... der er meget eksisterende dokumentation.

Oversigt over fællesskabet, hvordan udvikling fungerer

PostgreSQL er udviklet og vedligeholdt af et globalt spredt netværk af højtuddannede frivillige, der brænder for relationel database computing kaldet PostgreSQL Global Development Group. En håndfuld kerneteammedlemmer varetager sammen særlige ansvarsområder som at koordinere udgivelsesaktiviteter, særlig intern kommunikation, politikmeddelelser, overvåge forpligtelsesprivilegier og hostinginfrastrukturen, disciplinære og andre ledelsesspørgsmål samt individuelt ansvar for specialkodning, udvikling og vedligeholdelsesbidrag. . Omkring fyrre yderligere personer betragtes som væsentlige bidragydere, der som navnet antyder, har påtaget sig omfattende udviklings- eller vedligeholdelsesaktiviteter for væsentlige kodebasefunktioner eller nært beslægtede projekter. Og flere dusin flere personer yder aktivt forskellige andre bidrag. Bortset fra de aktive bidragydere, er en lang liste af tidligere bidragydere anerkendt for arbejdet med projektet. Det er dette teams dygtighed og høje standarder, der har resulteret i det rige og robuste funktionssæt i PostgreSQL.

Mange af bidragyderne har fuldtidsjob, der relaterer direkte til PostgreSQL eller anden Open Source-software, og den entusiastiske støtte fra deres arbejdsgivere gør deres varige engagement med PostgreSQL-fællesskabet muligt.

Bidragende enkeltpersoner koordinerer ved hjælp af samarbejdsværktøjer såsom Internet Relay Chat (irc://irc.freenode.net/PostgreSQL) og PostgreSQL-fællesskabsmailinglister (https://www.PostgreSQL.org/community/lists). Hvis du er ny på IRC eller mailinglister, så gør en indsats specifikt for at læse op på etikette og protokoller (en god artikel vises på https://fedoramagazine.org/beginners-guide-irc/), og efter du har tilmeldt dig, skal du bruge noget tid bare at lytte til igangværende samtaler og søge i arkiverne for tidligere lignende spørgsmål, før du hopper ind med dine egne problemer.

Bemærk, at holdet ikke er statisk:Enhver kan blive bidragyder ved, ja, at bidrage … men dit bidrag forventes at opfylde de samme høje standarder!

Holdet vedligeholder en Wiki-side (https://wiki.postgresql.org/), der blandt en masse meget detaljerede og nyttige oplysninger som artikler, tutorials, kodestykker og mere præsenterer en TODO-liste over PostgreSQL-fejl og funktionsanmodninger og andre områder, hvor der kan være behov for en indsats. Hvis du vil være en del af teamet, er dette et godt sted at browse. Elementer tilføjes kun efter grundig diskussion på udviklerens mailingliste.

Fællesskabet følger en proces, visualiseret som trinene i figur 1.

Det vil sige, at værdien af ​​enhver ikke-triviel ny kodeimplementering forventes først at blive diskuteret og vurderet (ved konsensus) at være ønskelig. Derefter investeres der i design:design af grænsefladen, syntaks, semantik og adfærd og overvejelser om bagudkompatibilitetsproblemer. Du ønsker at få buy-in fra udviklerfællesskabet om, hvad der er problemet, der skal løses, og hvad denne implementering vil opnå. Du vil bestemt IKKE gå ud og udvikle noget i et vakuum på egen hånd. Der er bogstaveligt talt årtier værd af kollektiv erfaring af meget høj kvalitet, der er inkorporeret i teamet, og du ønsker, og de forventer, at få ideer undersøgt tidligt.

PostgreSQL-kildekoden gemmes og administreres ved hjælp af Git-versionskontrolsystemet, så en lokal kopi kan tjekkes ud fra https://git.postgresql.org/ for at påbegynde implementeringen. Bemærk, at for holdbar vedligeholdelse skal patches smelte sammen med omgivende kode og følge de etablerede kodningskonventioner (http://developer.postgresql.org/pgdocs/postgres/source.html), så det er en god idé at studere enhver lignende kode sektioner for at lære og efterligne konventionerne. Generelt bruges standardformatet BSD-stil. Sørg også for at opdatere dokumentationen efter behov.

Test indebærer først at sikre, at eksisterende regressionstest lykkes, og at der ikke er nogen kompilatoradvarsler, men også at tilføje tilsvarende nye test for at udøve de(n) nyligt implementerede funktion(er).

Når den nye funktionalitetsimplementering i dit lokale lager er færdig, skal du bruge Git diff-funktionaliteten til at oprette en patch. Patches sendes via e-mail til pgsql-hackers mailingliste til gennemgang og kommentarer, men du behøver ikke vente, indtil dit arbejde er færdigt ... smart praksis ville være at bede om feedback trinvist. Wiki-siden beskriver forventninger til format og nyttig forklarende kontekst, og hvordan man viser respekt for kodeanmelderens tid.

Kerneudviklerne planlægger periodisk commit-fests, hvor alle akkumulerede uanvendte patches føjes til kildekodelageret af autoriserede committere. Som bidragyder vil din kode have gennemgået en grundig gennemgang, og dine egne udviklerevner vil sandsynligvis være de bedste for det. For at gengælde tjenesten er der en forventning om, at du vil bruge tid på at gennemgå patches fra andre.

Topwebsteder til at få information eller lære PostgreSQL

De få værktøjer, du ikke kan leve uden

De grundlæggende kommandolinjeværktøjer til at arbejde med en PostgreSQL-database er en del af den normale distribution. Arbejdshesten er kommandolinjeværktøjet psql, som giver en interaktiv grænseflade med masser af funktionalitet til forespørgsel, visning og ændring af databasemetadata samt udførelse af datadefinition (DDL) og datamanipulation (DML) sætninger.

Andre inkluderede værktøjer inkluderer pg_basebackup til at etablere en baseline for replikeringsbaseret backup, pg_dump til at udtrække en database til en scriptfil eller anden arkivfil, pg_restore til at gendanne en fra et pg_dump-arkiv og andre. Alle disse værktøjer har fremragende manualsider og er detaljerede i standarddokumentationen og adskillige online tutorials.

pgAdmin er et meget populært grafisk brugergrænsefladeværktøj, der giver lignende funktionalitet som psql-kommandolinjeværktøjet, men med peg-og-klik bekvemmelighed. Figur 2 viser et skærmbillede af pgAdmin III. Til venstre er et panel, der viser alle databaseobjekterne i klyngen på den tilsluttede værtsserver. Du kan bore ned i strukturen for at liste alle databaser, skemaer, tabeller, visninger, funktioner osv. og endda åbne tabeller og visninger for at undersøge de indeholdte data. For hvert objekt vil værktøjet oprette SQL DML til at slippe og genskabe objektet, som vist i nederste højre panel. Dette er en bekvem måde at foretage ændringer under databaseudvikling.

Et par af mine foretrukne værktøjer til applikationsudviklerteams er Sqitch (http://sqitch.org/), til databaseændringskontrol og pgTAP (http://pgtap.org/). Sqitch muliggør selvstændig ændringsstyring og iterativ udvikling ved hjælp af scripts skrevet på SQL-dialekten, der er indbygget i din implementering, ikke kun PostgreSQL. For hver databasedesignændring skriver du tre scripts:et til at implementere ændringen, et til at fortryde ændringen, hvis det er nødvendigt at vende tilbage til en tidligere version, og et til at verificere eller teste ændringen. Scripts og relaterede filer kan vedligeholdes i dit revisionskontrolsystem lige ved siden af ​​din applikationskode. PgTAP er en testramme, der inkluderer en række funktioner til at verificere databasens integritet. Alle pgTAP-scripts er på samme måde almindelige tekstfiler, der er kompatible med normal revisionsstyring og ændringskontrolprocesser. Da jeg først begyndte at bruge disse to værktøjer, havde jeg svært ved at forestille mig nogensinde igen at lave databasearbejde uden.

Tips og tricks

PostgreSQL's generelle postliste er den mest aktive af de forskellige fællesskabslister og er den vigtigste fællesskabsgrænseflade for gratis support til brugere. En temmelig bred vifte af spørgsmål vises på denne liste, som nogle gange genererer lange frem og tilbage, men som oftest får hurtige, informative og konkrete svar.

Når du sender et spørgsmål relateret til brugen af ​​PostgreSQL, vil du generelt altid inkludere baggrundsinformation, herunder den version af PostgreSQL, du bruger (angivet af psql-kommandolinjeværktøjet med "psql --version"), operativsystemet som serveren er på. kører, og så måske en beskrivelse af driftsmiljøet, såsom om det overvejende kan være læsetungt eller skrivetungt, typisk antal brugere og samtidighedsproblemer, ændringer du har foretaget fra standardserverkonfigurationen (dvs. pg_hba.conf og postgresql.conf filer), osv. Ofte er en beskrivelse af, hvad du forsøger at opnå, værdifuld, snarere end en stump analogi, da du godt kan få forslag til forbedringer, som du ikke engang havde tænkt på på egen hånd. Du vil også få det bedste svar, hvis du inkluderer faktiske DDL, DML og eksempeldata, der illustrerer problemet og gør det lettere for andre at genskabe det, du ser -- ja, folk vil faktisk køre din prøvekode og arbejde med dig.

Derudover, hvis du spørger om at forbedre forespørgselsydeevnen, vil du give forespørgselsplanen, dvs. EXPLAIN-outputtet. Dette genereres ved at køre din forespørgsel uændret, bortset fra at det bogstaveligt talt indsættes ordet "EXPLAIN", som vist i figur 3 i pgAdmin-værktøjet eller psql-kommandolinjeværktøjet.

Under EXPLAIN returnerer serveren i stedet for faktisk at køre forespørgslen forespørgselsplanen, som viser detaljeret output af, hvordan forespørgslen vil blive udført, herunder hvilke indekser der vil blive brugt til at optimere dataadgang, hvor tabelscanninger kan finde sted, og estimater af omkostninger og mængde af data involveret i hvert trin. Den slags hjælp, du vil få fra de erfarne praktiserende læger, der overvåger mailinglisten, kan identificere problemer og hjælpe med at foreslå mulige nye indekser eller ændringer af filtrerings- eller joinkriterierne.

Til sidst, når du deltager i mailinglistediskussioner, er der to vigtige ting, du vil huske på.

For det første er maillisteserveren sat op til at sende beskeder, der er konfigureret således, at når du svarer, vil din mailsoftware som standard kun svare til den oprindelige beskedforfatter. For at være sikker på, at din besked går til listen, skal du bruge din mail-software "svar-alle"-funktion, som så vil inkludere både meddelelsens forfatter og listens adresse.

For det andet er konventionen på PostgreSQL-mailinglisterne at svare in-line og IKKE TOP POST. Dette sidste punkt er en langvarig konvention i dette samfund, og for mange nytilkomne virker det usædvanligt nok til, at milde formaninger er meget almindelige. Der er forskellige meninger om, hvor meget af den originale meddelelse, der skal beholdes til kontekst i dit svar. Nogle mennesker gnaver over den til tider uhåndterlige vækst i meddelelsens størrelse, når hele den oprindelige meddelelse bevares i en masse frem og tilbage diskussion. Personligt kan jeg godt lide at slette alt, der ikke er relevant for det, jeg specifikt svarer på, for at holde beskeden kortfattet og fokuseret. Bare husk på, at der er årtiers mailingliste-historie bevaret online til historisk dokumentation og fremtidig forskning, så det anses for meget vigtigt at bevare kontekst og flow.

Denne artikel får dig i gang, gå nu videre og dyk ned!