Tips och knep för att navigera i PostgreSQL-communityt

Den här bloggen handlar om PostgreSQL-communityt, hur det fungerar och hur man bäst navigerar i det. Observera att detta bara är en översikt ... det finns en hel del befintlig dokumentation.

Översikt över gemenskapen, hur utveckling fungerar

PostgreSQL utvecklas och underhålls av ett globalt spritt nätverk av högkvalificerade volontärer som brinner för relationsdatabasberäkningar som kallas PostgreSQL Global Development Group. En handfull kärngruppsmedlemmar hanterar tillsammans speciella ansvarsområden som att koordinera frigivningsaktiviteter, speciell intern kommunikation, policymeddelanden, övervaka åtagandeprivilegier och värdinfrastrukturen, disciplinära och andra ledarskapsfrågor samt individuellt ansvar för specialitetskodning, utveckling och underhållsbidrag. . Ytterligare ett fyrtiotal personer anses vara stora bidragsgivare som har, som namnet antyder, genomfört omfattande utvecklings- eller underhållsaktiviteter för betydande kodbasfunktioner eller närbesläktade projekt. Och flera dussin personer till gör aktivt olika andra bidrag. Förutom de aktiva bidragsgivarna, är en lång lista av tidigare bidragsgivare uppmärksammade för arbetet med projektet. Det är det här teamets skicklighet och höga standard som har resulterat i den rika och robusta funktionsuppsättningen i PostgreSQL.

Många av bidragsgivarna har heltidsjobb som direkt relaterar till PostgreSQL eller annan öppen källkod, och det entusiastiska stödet från deras arbetsgivare gör deras varaktiga engagemang med PostgreSQL-gemenskapen möjlig.

Bidragande individer koordinerar med hjälp av samarbetsverktyg som Internet Relay Chat (irc://irc.freenode.net/PostgreSQL) och PostgreSQL-gemenskapens e-postlistor (https://www.PostgreSQL.org/community/lists). Om du är ny på IRC eller e-postlistor, ansträng dig specifikt för att läsa på om etikett och protokoll (en bra artikel finns på https://fedoramagazine.org/beginners-guide-irc/), och spendera när du har gått med lite tid att bara lyssna på pågående konversationer och söka i arkiven efter tidigare liknande frågor innan du hoppar in med dina egna frågor.

Observera att laget inte är statiskt:vem som helst kan bli bidragsgivare genom att, ja, bidra ... men ditt bidrag förväntas uppfylla samma höga krav!

Teamet har en Wiki-sida (https://wiki.postgresql.org/) som, bland mycket detaljerad och användbar information som artiklar, tutorials, kodavsnitt och mer, presenterar en TODO-lista med PostgreSQL-buggar och funktionsförfrågningar och andra områden där insatser kan behövas. Om du vill vara en del av teamet är det här ett bra ställe att surfa på. Objekt läggs till endast efter noggrann diskussion på utvecklarens e-postlista.

Gemenskapen följer en process, visualiserad som stegen i figur 1.

Det vill säga, värdet av varje icke-trivial ny kodimplementering förväntas först diskuteras och anses (i samförstånd) vara önskvärd. Sedan investeras i design:utformning av gränssnittet, syntax, semantik och beteenden, och övervägande av problem med bakåtkompatibilitet. Du vill få inköp från utvecklargemenskapen om vad som är problemet som ska lösas och vad den här implementeringen kommer att åstadkomma. Du vill definitivt INTE gå iväg och utveckla något i ett vakuum på egen hand. Det finns bokstavligen decennier värda av mycket högkvalitativ kollektiv erfarenhet i teamet, och du vill, och de förväntar sig, att få idéer granskade tidigt.

PostgreSQL-källkoden lagras och hanteras med hjälp av Git-versionskontrollsystemet, så en lokal kopia kan checkas ut från https://git.postgresql.org/ för att påbörja implementeringen. Observera att för hållbart underhåll måste patchar smälta in med omgivande kod och följa de etablerade kodningskonventionerna (http://developer.postgresql.org/pgdocs/postgres/source.html), så det är en bra idé att studera liknande kod avsnitt för att lära sig och efterlikna konventionerna. I allmänhet används standardformatet BSD-stil. Se också till att uppdatera dokumentationen vid behov.

Testning innebär att först se till att befintliga regressionstester lyckas och att det inte finns några kompilatorvarningar, men också att lägga till motsvarande nya tester för att utöva de nyligen implementerade funktionerna.

När den nya funktionalitetsimplementeringen i ditt lokala arkiv är klar, använd Git diff-funktionaliteten för att skapa en patch. Patchar skickas via e-post till pgsql-hackers e-postlista för granskning och kommentarer, men du behöver inte vänta tills ditt arbete är klart ... smart praxis skulle vara att be om feedback stegvis. Wiki-sidan beskriver förväntningar på format och användbart förklarande sammanhang och hur man visar respekt för kodgranskarens tid.

Kärnutvecklarna schemalägger regelbundet commit-fester, under vilka alla ackumulerade oapplicerade patchar läggs till i källkodsförrådet av auktoriserade committers. Som bidragsgivare kommer din kod att ha genomgått en noggrann granskning och sannolikt kommer dina egna utvecklarkunskaper att vara bättre för den. För att ge tillbaka en tjänst förväntas du ägna tid åt att granska patchar från andra.

Bästa webbplatser för att få information eller lära dig PostgreSQL

De få verktyg du inte kan leva utan

De grundläggande kommandoradsverktygen för att arbeta med en PostgreSQL-databas är en del av normaldistributionen. Arbetshästen är kommandoradsverktyget psql, som tillhandahåller ett interaktivt gränssnitt med massor av funktioner för att söka, visa och ändra databasmetadata, samt exekvera datadefinition (DDL) och datamanipulation (DML) uttalanden.

Andra inkluderade användbara verktyg inkluderar pg_basebackup för att upprätta en baslinje för replikeringsbaserad säkerhetskopiering, pg_dump för att extrahera en databas till en skriptfil eller annan arkivfil, pg_restore för att återställa en från ett pg_dump-arkiv och andra. Alla dessa verktyg har utmärkta manualsidor och är detaljerade i standarddokumentationen och många onlinehandledningar.

pgAdmin är ett mycket populärt grafiskt användargränssnittsverktyg som ger liknande funktionalitet som kommandoradsverktyget psql, men med peka-och-klicka bekvämlighet. Figur 2 visar en skärmdump av pgAdmin III. Till vänster finns en panel som visar alla databasobjekt i klustret på den anslutna värdservern. Du kan borra ner i strukturen för att lista alla databaser, scheman, tabeller, vyer, funktioner, etc, och till och med öppna tabeller och vyer för att undersöka de ingående data. För varje objekt kommer verktyget att skapa SQL DML för att släppa och återskapa objektet, som visas på den nedre högra panelen. Detta är ett bekvämt sätt att göra ändringar under databasutveckling.

Ett par av mina favoritverktyg för applikationsutvecklare är Sqitch (http://sqitch.org/), för databasändringskontroll och pgTAP (http://pgtap.org/). Sqitch möjliggör fristående förändringshantering och iterativ utveckling med hjälp av skript skrivna på SQL-dialekten som är inbyggd i din implementering, inte bara PostgreSQL. För varje databasdesignändring skriver du tre skript:ett för att distribuera ändringen, ett för att ångra ändringen om det skulle behövas en återgång till en tidigare version och ett för att verifiera eller testa ändringen. Skripten och relaterade filer kan underhållas i ditt revisionskontrollsystem bredvid din applikationskod. PgTAP är ett testramverk som inkluderar en uppsättning funktioner för att verifiera databasens integritet. Alla pgTAP-skript är likaledes vanliga textfiler som är kompatibla med normal revisionshantering och ändringskontrollprocesser. När jag väl började använda dessa två verktyg, fann jag det svårt att föreställa mig att någonsin göra databasarbete utan.

Tips och tricks

PostgreSQL:s allmänna e-postlista är den mest aktiva av de olika gemenskapslistorna och är det huvudsakliga gemenskapsgränssnittet för gratis support till användare. Ett ganska brett spektrum av frågor dyker upp på den här listan, som ibland genererar långa fram och tillbaka, men får oftast snabba, informativa och raka svar.

När du ställer en fråga relaterad till PostgreSQL vill du i allmänhet alltid inkludera bakgrundsinformation inklusive den version av PostgreSQL du använder (listad av psql kommandoradsverktyget med "psql --version"), operativsystemet där servern är körs, och sedan kanske en beskrivning av operativmiljön, till exempel om den övervägande kan vara lästung eller skrivtung, typiskt antal användare och samtidighetsproblem, ändringar du har gjort från standardserverkonfigurationen (dvs. pg_hba.conf och postgresql.conf-filer), etc. Ofta är en beskrivning av vad du försöker åstadkomma värdefull, snarare än någon trubbig analogi, eftersom du mycket väl kan få förslag till förbättringar som du inte ens hade tänkt på på egen hand. Du kommer också att få det bästa svaret om du inkluderar faktiska DDL, DML och exempeldata som illustrerar problemet och underlättar för andra att återskapa det du ser -- ja, folk kommer faktiskt att köra din exempelkod och arbeta med dig.

Dessutom, om du frågar om att förbättra frågeprestanda, kommer du att vilja tillhandahålla frågeplanen, d.v.s. EXPLAIN-utdata. Detta genereras genom att köra din fråga oförändrad förutom att prefixet bokstavligen med ordet "EXPLAIN", som visas i figur 3 i pgAdmin-verktyget eller psql-kommandoradsverktyget.

Under EXPLAIN, istället för att faktiskt köra frågan, returnerar servern frågeplanen, som listar detaljerad utdata för hur frågan kommer att exekveras, inklusive vilka index som kommer att användas för att optimera dataåtkomst, var tabellsökningar kan ske och uppskattningar av kostnad och mängd data som ingår i varje steg. Den typ av hjälp du kommer att få från de erfarna utövarna som övervakar e-postlistan kan lokalisera problem och hjälpa till att föreslå möjliga nya index eller ändringar av filtrerings- eller anslutningskriterierna.

Slutligen, när du deltar i diskussioner om e-postlistor finns det två viktiga saker du vill ha i åtanke.

Först är e-postlistservern inställd för att skicka meddelanden som är konfigurerade så att när du svarar, som standard kommer din e-postprogramvara endast att svara på den ursprungliga meddelandeförfattaren. För att vara säker på att ditt meddelande hamnar i listan måste du använda funktionen "svara alla" i e-postprogramvaran, som då inkluderar både meddelandeförfattaren och listans adress.

För det andra är konventionen på PostgreSQL-sändlistorna att svara på nätet och INTE TOPPA POST. Denna sista punkt är en långvarig konvention i det här samhället, och för många nykomlingar verkar det ovanligt nog att milda förmaningar är mycket vanliga. Åsikterna varierar om hur mycket av det ursprungliga meddelandet som ska behållas för sammanhang i ditt svar. Vissa människor skaver på den ibland otympliga ökningen i storlek på meddelandet när hela det ursprungliga meddelandet behålls i massor av diskussioner fram och tillbaka. Jag personligen gillar att ta bort allt som inte är relevant för det jag specifikt svarar på för att hålla meddelandet kortfattat och fokuserat. Tänk bara på att det finns decennier av e-postlistas historik bevarad online för historisk dokumentation och framtida forskning, så att behålla sammanhang och flöde anses mycket viktigt.

Den här artikeln hjälper dig att komma igång, fortsätt nu och dyk in!