Överväganden vid användning av tillägg och moduler

2025-03-26

Den här artikeln beskriver några särskilda överväganden som du måste känna till när du använder vissa tillägg eller moduler i en flexibel Azure Database for PostgreSQL-server.

Allmänna överväganden med tillägg

Om du vill använda ett tillägg i din flexibla Azure Database for PostgreSQL-server måste du:

Tillåt tillägg. Om tillägget inte är tillåtet kan ett försök att köra CREATE EXTENSION, ALTER EXTENSION, DROP EXTENSIONeller COMMENT ON EXTENSION misslyckas med ett fel som anger att det refererade tillägget inte är tillåtet.
Om tillägget distribuerar ett delat binärt bibliotek som kräver allokering och åtkomst till delat minne och måste läsas in när servern startar, bör du också följa anvisningarna i belastningsbibliotek.
Skapa tillägget i de databaser där du vill att tillägget ska distribuera SQL-objekten som distribueras med tillägget.
Släpp tillägget. När du vill ta bort från databasen där du kör kommandot alla SQL-objekt som distribueras av tillägget.
Uppdatera tillägg för att uppdatera till den senaste versionen av alla SQL-artefakter som distribuerats av ett tillägg som redan är installerat.
Visa installerade tillägg och deras motsvarande versioner.

Om du får något fel när du kör kommandona CREATE EXTENSION, ALTER EXTENSIONDROP EXTENSIONeller COMMENT ON EXTENSION på din flexibla Azure Database for PostgreSQL-server kan du läsa listan över möjliga fel och vad som kan vara orsaken till vart och ett av dessa fel.

Allmänna överväganden med moduler

Om du vill använda en modul i din flexibla Azure Database for PostgreSQL-server behöver du bara lägga till den i serverparametern enligt beskrivningen shared_preload_libraries i belastningsbibliotek.

Moduler behöver inte tillåtas. Det är ett exklusivt krav för tillägg.

Tillägg med specifika överväganden

I följande lista räknas alla tillägg som stöds upp som kräver specifika överväganden när de används i en flexibel Azure Database for PostgreSQL-server:

AGE
dblink
pg_buffercache
pg_cron
pg_hint_plan
pg_prewarm
pg_repack
pg_stat_statements
postgres_fdw
pgstattuple

ÅLDER

Apache AGE-tillägget är ett graftillägg för PostgreSQL som stöds av en flexibel Azure Database for PostgreSQL-server. Den innehåller funktioner för grafdatabaser, stöd för öppna cypher-frågor och möjligheten att köra komplexa frågor på grafdata som lagras i PostgreSQL. Apache AGE är ett projekt med öppen källkod som lanseras under Apache License 2.0.

Installera AGE

Om du vill använda AGE ska du "tillåta" tillägget, läsa in dess bibliotek och "installera tillägget" i databasen där du planerar att använda dess funktioner.

dblink

Med dblink tillägget kan du ansluta från en flexibel Azure Database for PostgreSQL-serverinstans till en annan eller en annan databas på samma server. Azure Database for PostgreSQL – flexibel server stöder både inkommande och utgående anslutningar till valfri PostgreSQL-server. Den sändande servern måste tillåta utgående anslutningar till den mottagande servern. På samma sätt måste den mottagande servern tillåta anslutningar från den sändande servern.

Om du planerar att använda det här tillägget rekommenderar vi att du distribuerar dina servrar med integrering av virtuella nätverk. Som standard tillåter integrering av virtuella nätverk anslutningar mellan servrar i det virtuella nätverket. Du kan också välja att använda säkerhetsgrupper för virtuella nätverk för att anpassa åtkomsten.

pg_buffercache

Tillägget pg_buffercache kan användas för att studera innehållet i shared_buffers. Med det här tillägget kan du se om en viss relation cachelagras (i shared_buffers). Det här tillägget kan hjälpa dig att felsöka prestandaproblem (cachelagringsrelaterade prestandaproblem).

Det här tillägget är integrerat med kärninstallationen av PostgreSQL, och det är enkelt att installera.

CREATE EXTENSION pg_buffercache;

pg_cron

Tillägget pg_cron är en enkel, cron-baserad jobbschemaläggare för PostgreSQL som körs i databasen som ett tillägg. Tillägget pg_cron kan köra schemalagda underhållsaktiviteter i en PostgreSQL-databas. Du kan till exempel köra ett periodiskt vakuum av en tabell eller ta bort gamla datajobb.

Tillägget pg_cron kan köra flera jobb parallellt, men det körs högst en instans av ett jobb i taget. Om en andra körning ska starta innan den första slutförs placeras den andra körningen i kö och startas så snart den första körningen är klar. På ett sådant sätt säkerställer det att jobb körs exakt lika många gånger som schemalagt och inte körs samtidigt med sig själva.

Kontrollera att värdet som shared_preload_libraries har angetts innehåller pg_cron. Det här tillägget stöder inte inläsning av biblioteket som effekten av att köra CREATE-TILLÄGGET. Alla försök att köra CREATE EXTENSION om tillägget inte lades till shared_preload_librariesi , eller om servern inte startades om efter att det lades till, resulterar i ett fel vars text säger pg_cron can only be loaded via shared_preload_libraries, och vars tips är Add pg_cron to the shared_preload_libraries configuration variable in postgresql.conf.

Om du vill använda pg_cronkontrollerar du att du läser in dess delade bibliotek vid serverstart, att det är tillåtetlistat och att det är installerat i alla databaser som du vill interagera med dess funktioner från, med hjälp av de SQL-artefakter som skapas.

Exempel

Ta bort gamla data på lördag klockan 03:30 (GMT).

SELECT cron.schedule('30 3 * * 6', $$DELETE FROM events WHERE event_time < now() - interval '1 week'$$);

Så här kör du vakuumet varje dag klockan 10:00 (GMT) i standarddatabasen postgres.
```
SELECT cron.schedule('0 10 * * *', 'VACUUM');
```
Så här avbokar du alla aktiviteter från pg_cron.
```
SELECT cron.unschedule(jobid) FROM cron.job;
```
Om du vill se alla jobb som för närvarande är schemalagda med pg_cron.
```
SELECT * FROM cron.job;
```
För att köra vakuumet varje dag klockan 10:00 (GMT) i databasen test cron under azure_pg_admin rollkontot.
```
SELECT cron.schedule_in_database('VACUUM',' 0 10 * * * ', 'VACUUM', 'testcron',null,TRUE);
```

Fler exempel

Från och med pg_cron version 1.4 kan du använda cron.schedule_in_database funktionerna och cron.alter_job för att schemalägga jobbet i en specifik databas och uppdatera ett befintligt schema.

Funktionen cron_schedule_in_database tillåter användarnamnet som en valfri parameter. Om du ställer in användarnamnet på ett värde som inte är null krävs postgreSQL-superanvändarbehörighet och stöds inte i Azure Database for PostgreSQL – flexibel server. Föregående exempel visar körning av den här funktionen med en valfri användarnamnsparameter utelämnad eller inställd på null, som kör jobbet i kontexten för användaren som schemalägger jobbet, som ska ha azure_pg_admin rollbehörigheter.

Ta bort gamla data på lördag klockan 03:30 (GMT) på databasen DBName.

SELECT cron.schedule_in_database('JobName', '30 3 * * 6', $$DELETE FROM events WHERE event_time < now() - interval '1 week'$$,'DBName');

För att uppdatera eller ändra databasnamnet för det befintliga schemat
```
SELECT cron.alter_job(job_id:=MyJobID,database:='NewDBName');
```

pg_hint_plan

Tillägget pg_hint_plan gör det möjligt att justera PostgreSQL-körningsplaner med hjälp av så kallade "tips" i SQL-kommentarer, till exempel:

/*+ SeqScan(a) */

Tillägget pg_hint_plan läser tipsfraser i en kommentar av det särskilda formulär som ges med SQL-mål-instruktionen. Det specifika formuläret börjar med teckensekvensen "/*+" och slutar med "*/". Tipsfraser består av tipsnamn och följande parametrar som omges av parenteser och avgränsas av blanksteg. Nya rader för läsbarhet kan avgränsa varje tipsfras.

Exempel:

/*+
 HashJoin(a b)
 SeqScan(a)
 */
    SELECT *
    FROM pgbench_branches b
    JOIN pgbench_accounts an ON b.bid = a.bid
    ORDER BY a.aid;

Det föregående exemplet gör att planeraren använder resultatet av en seqscan på-tabell a för att kombinera med tabellen b som en hashjoin.

Om du vill använda pg_hint_plan tillägget kontrollerar du att du tillåterlistning av tillägget, läser in dess bibliotek och installerar tillägget i databasen där du planerar att använda dess funktioner.

pg_prewarm

Tillägget pg_prewarm läser in relationsdata i cacheminnet. Att förvärma dina cacheminnen innebär att dina frågor har bättre svarstider vid den första körningen efter en omstart. Funktionen autoprewarm för den flexibla PostgreSQL-servern är för närvarande inte tillgänglig i Azure Database.

pg_repack

Första gången användare av pg_repack tillägget vanligtvis ställer följande fråga: Kan pg_repack ett tillägg eller en körbar klientsida som psql eller pg_dump?

pg_repack är faktiskt både och. pg_repack/lib har koden för tillägget, inklusive schemat och SQL-artefakterna som skapas, och C-biblioteket som implementerar koden för flera av dessa funktioner.

Å andra sidan har pg_repack/bin koden för klientprogrammet, som vet hur man interagerar med programmeringselementen som implementeras i tillägget. Det här klientprogrammet syftar till att underlätta komplexiteten i att interagera med de olika gränssnitten som visas av tillägget på serversidan. Det ger användaren vissa kommandoradsalternativ som är lättare att förstå. Klientprogrammet är värdelöst utan tillägget som skapas i databasen som det pekar på. Tillägget på serversidan är helt funktionellt, men kräver att användaren förstår ett komplicerat interaktionsmönster. Det mönstret skulle bestå av att köra frågor för att hämta data som används som indata till funktioner som implementeras av tillägget osv.

Behörighet nekad för schemaompaketering

Eftersom vi beviljar behörigheter till det ompaketeringsschema som skapats av det här tillägget stöder vi för närvarande endast körningsfunktioner pg_repackazure_pg_adminfrån kontexten för .

Du kanske märker att om ägaren till en tabell, som inte azure_pg_adminär , försöker köra pg_repackfår de följande fel:

NOTICE: Setting up workers.conns
ERROR: pg_repack failed with error: ERROR:  permission denied for schema repack
LINE 1: select repack.version(), repack.version_sql()

Undvik det felet genom att köra pg_repack från kontexten azure_pg_adminför .

pg_stat_statements

Tillägget pg_stat_statements ger dig en vy över alla frågor som körs i databasen. Den här informationen är användbar för att förstå frågearbetsbelastningens prestanda i ett produktionssystem.

Tillägget pg_stat_statements är förinläst på shared_preload_libraries varje flexibel Azure Database for PostgreSQL-serverinstans för att tillhandahålla ett sätt att spåra SQL-instruktionens körningsstatistik.

Av säkerhetsskäl måste du tillåtalistning av pg_stat_statements-tillägget och installera det med kommandot CREATE EXTENSION .

Inställningen pg_stat_statements.track, som styr vilka instruktioner tillägget spårar, är standardvärdet , vilket innebär att topalla instruktioner som utfärdas direkt av klienter spåras. De två andra spårningsnivåerna är none och all. Den här inställningen kan konfigureras som en serverparameter.

Det finns en kompromiss mellan frågekörningsinformationen som pg_stat_statements tillägget tillhandahåller på serverns prestanda när varje SQL-instruktion loggas. Om du inte aktivt använder pg_stat_statements tillägget rekommenderar vi att du anger pg_stat_statements.track till none. Vissa övervakningstjänster från tredje part kan förlita sig på pg_stat_statements för att leverera insikter om frågeprestanda, så bekräfta om det är fallet för dig.

postgres_fdw

Med postgres_fdw tillägget kan du ansluta från en flexibel Azure Database for PostgreSQL-serverinstans till en annan eller en annan databas på samma server. Azure Database for PostgreSQL – flexibel server stöder både inkommande och utgående anslutningar till valfri PostgreSQL-server. Den sändande servern måste tillåta utgående anslutningar till den mottagande servern. På samma sätt måste den mottagande servern tillåta anslutningar från den sändande servern.

pgstattuple

När du använder pgstattuple tillägget för att försöka hämta tuppelns statistik från objekt som lagras i pg_toast schemat i versioner av Postgres 11 till 13 får du felet "behörighet nekad för schema pg_toast".

Behörighet nekad för schema pg_toast

Kunder som använder PostgreSQL version 11 till och med 13 på Azure Database för flexibel server| kan inte använda pgstattuple tillägget på objekt i pg_toast schemat.

I PostgreSQL 16 och 17 beviljas rollen automatiskt till pg_read_all_data, vilket gör azure_pg_admin att den pgstattuple kan fungera korrekt. I PostgreSQL 14 och 15 kan kunderna manuellt ge pg_read_all_data rollen för att azure_pg_admin uppnå samma resultat. Men i PostgreSQL 11 till 13 pg_read_all_data finns inte rollen.

Kunder kan inte bevilja nödvändiga behörigheter direkt. Om du behöver kunna köra för att komma pgstattuple åt objekt under pg_toast schemat fortsätter du med att skapa en Azure Support begäran.

timescaleDB

Tillägget timescaleDB är en tidsseriedatabas som paketeras som ett tillägg för PostgreSQL. Den tillhandahåller tidsorienterade analysfunktioner och optimeringar och skalar Postgres för tidsseriearbetsbelastningar. Läs mer om TimescaleDB, ett registrerat varumärke som tillhör Timescale, Inc. Azure Database for PostgreSQL – flexibel server tillhandahåller TimescaleDB Apache-2-utgåvan.

Installera TimescaleDB

Om du vill använda timescaleDBkontrollerar du att du tillåterlistning av tillägget, läser in dess bibliotek och installerar tillägget i databasen där du planerar att använda dess funktioner.

Nu kan du skapa en TimescaleDB-hypertabell från grunden eller migrera befintliga tidsseriedata i PostgreSQL.

Mer information om hur du återställer en tidsskala-databas med hjälp av pg_dump och pg_restorefinns i Dokumentation om tidsskala.

Återställa en tidsskala-databas med hjälp av tidsberäknadb-säkerhetskopiering

När du kör proceduren SELECT timescaledb_post_restore() kan du få behörigheter som nekas när du uppdaterar flaggan timescaledb.restoring. Anledningen till att du får det här felet beror på den begränsade ALTER DATABASE-behörigheten i Cloud PaaS-databastjänster. I det här fallet kan du utföra en alternativ metod med hjälp av timescaledb-backup verktyget för att säkerhetskopiera och återställa databasen Tidsskala. Timescaledb-backup är ett program som gör dumpning och återställning av en TimescaleDB-databas enklare, mindre felbenägen och mer högpresterande.

Följ stegen nedan:

Installera verktyg enligt beskrivningen här.
Skapa en Azure Database for PostgreSQL-målinstans och databas för flexibel server.
Aktivera tidsskaletillägg.
azure_pg_admin Bevilja rollen till den användare som används av ts-restore.
Kör ts-restore för att återställa databasen.

Mer information om dessa verktyg finns här.

Tillägg och högre versionsuppgradering

Azure Database for PostgreSQL – flexibel server erbjuder en huvudversionsuppgraderingsfunktion på plats som utför en uppgradering på plats av Azure Database for PostgreSQL flexibel serverinstans, med bara en enkel interaktion från användaren. Uppgradering av större versioner på plats förenklar uppgraderingsprocessen för Azure Database for PostgreSQL– flexibel server, vilket minimerar störningarna för användare och program som kommer åt servern. Huvudversionsuppgraderingar på plats stöder inte specifika tillägg, och det finns vissa begränsningar för att uppgradera vissa tillägg.

Tilläggen anon, Apache AGE, dblink, orafce, postgres_fdwoch timescaledb stöds inte för alla flexibla Azure Database for PostgreSQL-serverversioner när du använder huvudversionsuppdateringsfunktionen på plats.

Moduler med specifika överväganden

I följande lista räknas alla moduler som stöds upp som kräver specifika överväganden när de används i en flexibel Azure Database for PostgreSQL-server:

pg_failover_slots

pg_failover_slots

Modulen pg_failover_slots förbättrar Azure Database for PostgreSQL – flexibel server när du arbetar med både logisk replikering och servrar med hög tillgänglighet. Den hanterar effektivt utmaningen i PostgreSQL-standardmotorn som inte bevarar logiska replikeringsplatser efter en redundansväxling. Att underhålla dessa platser är viktigt för att förhindra replikeringspauser eller datamatchningar under ändringar av primär serverrollen, vilket säkerställer driftkontinuitet och dataintegritet.

Tillägget effektiviserar redundansväxlingen genom att hantera nödvändig överföring, rensning och synkronisering av replikeringsplatser, vilket ger en sömlös övergång under ändringar i serverrollen.

Du hittar mer information och instruktioner om hur du använder modulen pg_failover_slots på github-sidan.

Om du vill använda modulen pg_failover_slots kontrollerar du att biblioteket lästes in när servern startade.