Extensions are bolt-on modules that inject new types, functions, or index methods into PostgreSQL
CREATE EXTENSION reads a .control file, executes an SQL script, and registers objects in pg_extension
shared_preload_libraries is required for some extensions — missing it causes silent failure
HNSW indexes in pgvector cost 2-3x more disk space than IVFFlat but give ~5% better recall
Production trap: upgrading the OS package without running ALTER EXTENSION UPDATE leaves the DB version stale
Plain-English First
Think of PostgreSQL like a smartphone. It comes with a camera, phone app, and messages out of the box — but you can install apps to do way more. PostgreSQL extensions are those apps: bolt-on features that live inside the database itself, like GPS navigation or a video editor. You choose exactly which 'apps' your database needs. No bloat, no rewrites — just enable what you want and it's ready to use.
PostgreSQL ships as one of the most capable relational databases on the planet, but its real competitive edge isn't what it does by default — it's what it can become. Extensions let PostgreSQL morph into a time-series engine, a geospatial powerhouse, a vector similarity search system, or a statistical analysis platform without ever leaving SQL. This isn't a niche feature — it's the architectural choice that lets a single Postgres cluster replace entire categories of specialised databases.
The problem extensions solve is elegant: database internals are hard to change safely at runtime, but application requirements change constantly. Before extensions, adding new data types, indexing strategies, or procedural languages meant patching the core and recompiling. Extensions formalise a safe, versioned, reversible mechanism for injecting new capabilities into a live cluster — complete with dependency tracking, upgrade paths, and schema isolation. They're the reason PostGIS can add full geographic primitives and pgvector can power AI embedding search inside the same Postgres instance your users' accounts live in.
By the end of this article you'll know exactly how extensions work under the hood — from the shared object loading mechanism to the extension control file format. You'll be able to install and audit extensions safely in production, understand the performance implications of popular extensions, and build a minimal custom extension from scratch. No fluff, just the internals and the gotchas that bite in production.
How PostgreSQL Extensions Actually Work Internally
Every extension is made of three things: a shared object file (.so on Linux, .dll on Windows), a SQL script that defines objects in the database, and a control file that ties it all together. When you run CREATE EXTENSION, Postgres reads the control file from $sharedir/extension/, executes the install SQL script, and registers every object the extension created in the pg_extension and pg_depend system catalogs. That catalog registration is the secret sauce — it means Postgres knows which tables, functions, operators, and types belong to the extension, so DROP EXTENSION CASCADE can clean up everything safely.
The shared object is loaded into the backend process on first use via dlopen(). This means extension code runs in the same memory space as PostgreSQL itself. A poorly written C extension can segfault the entire backend — there's no sandbox. That's why extensions from trusted sources and your Linux package manager (postgresql-16-postgis-3, for example) are fundamentally safer than compiling random GitHub repos in production.
Extensions live in a specific schema (default: public, but you can redirect with the schema parameter). The search_path matters enormously here — if the extension's schema isn't on your search_path, function calls will fail with 'function not found' even though the extension is installed. Always check \dx in psql and pg_extension in SQL to see exactly what's active and which schema it landed in.
inspect_extensions.sqlSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
-- ============================================================-- Inspect everything PostgreSQL knows about installed extensions-- ============================================================-- 1. List all currently installed extensions with version and schemaSELECT
extname AS extension_name,
extversion AS installed_version,
nspname AS target_schema,
extrelocatable AS can_be_moved_to_other_schema
FROM pg_extension
JOIN pg_namespace ON pg_namespace.oid = pg_extension.extnamespace
ORDERBY extname;
-- 2. Show every object owned by the pg_stat_statements extension-- This reveals what CREATE EXTENSION actually createdSELECT
classid::regclass AS catalog_table, -- which system catalog the object lives in
objid::regprocedure AS object_signature -- the object itself, cast to readable formFROM pg_depend
WHERE deptype = 'e' -- 'e' means "owned by an extension"AND refobjid = (SELECT oid FROM pg_extension WHERE extname = 'pg_stat_statements')
LIMIT20;
-- 3. Check which extensions are AVAILABLE to install (not yet installed)SELECT
name AS extension_name,
default_version AS latest_version,
comment AS description
FROM pg_available_extensions
WHERE installed_version ISNULL-- NULL means not installed yetORDERBY name;
extrelocatable = false means the extension hard-codes its schema at install time — you cannot ALTER EXTENSION ... SET SCHEMA later. pg_stat_statements and plpgsql are both non-relocatable. Plan your schema layout before installing in production, not after.
Production Insight
The shared object runs in the backend's memory space — a segfault in an extension can crash the entire PostgreSQL backend process.
Trusted OS-package extensions are safer than compiling random GitHub repos.
Rule: when debugging crashes, isolate whether the extension .so is the cause by temporarily removing shared_preload_libraries entries.
Key Takeaway
pg_depend tracks every object an extension creates.
That's why DROP EXTENSION CASCADE is safe — Postgres knows exactly what to remove.
Always inspect pg_extension before making schema changes.
Installing and Managing Extensions in Production — The Right Way
Installing an extension is one line of SQL, but doing it safely in production involves four distinct steps that most tutorials skip entirely.
First, the shared library must exist on the filesystem of every PostgreSQL server in your cluster — including replicas, because replay of CREATE EXTENSION on a standby will fail if the .so file isn't present. This means your deployment pipeline must install the OS package before the SQL runs, not after.
Second, some extensions require preloading into shared memory at startup via shared_preload_libraries in postgresql.conf. pg_stat_statements is the classic example — if it's not in that list, CREATE EXTENSION succeeds but all the views return zero rows and no error is raised. Silent failure at its most frustrating.
Third, only superusers can CREATE EXTENSION by default. In managed cloud environments (RDS, Cloud SQL, AlloyDB) you get a pseudo-superuser role like rds_superuser that can install from a pre-approved allowlist. You cannot install arbitrary extensions on managed Postgres — this is a deliberate security boundary.
Fourth, extension upgrades are separate from OS package upgrades. Updating the debian package gets you new .so and SQL files on disk, but the database still runs the old version until you explicitly run ALTER EXTENSION name UPDATE. Both steps are required and order matters: package first, ALTER EXTENSION second.
production_extension_lifecycle.sqlSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
-- ============================================================-- Full production lifecycle: install, verify, upgrade, remove-- ============================================================-- STEP 1: Add to postgresql.conf BEFORE attempting install-- (Do this via ALTER SYSTEM so it's tracked in postgresql.auto.conf)ALTERSYSTEMSET shared_preload_libraries = 'pg_stat_statements, pg_prewarm';
-- This requires a cluster restart — check pending restart status:SELECT name, setting, pending_restart
FROM pg_settings
WHERE name = 'shared_preload_libraries';
-- STEP 2: After restart, install the extension into a dedicated schema-- Using a dedicated schema prevents extension objects polluting 'public'CREATESCHEMAIFNOTEXISTS monitoring;
CREATEEXTENSIONIFNOTEXISTS pg_stat_statements
SCHEMA monitoring; -- only works if extension is relocatable-- For non-relocatable extensions (like pg_stat_statements), install into public-- and control access via GRANT instead:CREATEEXTENSIONIFNOTEXISTS pg_stat_statements;
REVOKEALLONFUNCTIONpg_stat_statements_reset() FROMPUBLIC;
GRANTEXECUTEONFUNCTIONpg_stat_statements_reset() TO monitoring_role;
-- STEP 3: Verify it's collecting data (proves shared_preload_libraries worked)SELECT
calls,
mean_exec_time::numeric(10,3) AS avg_ms,
LEFT(query, 80) AS query_preview
FROM pg_stat_statements
ORDERBY total_exec_time DESCLIMIT5;
-- STEP 4: Upgrade workflow (after OS package update)-- Check current vs available versionSELECT
name,
installed_version,
default_version,
(installed_version <> default_version) AS upgrade_available
FROM pg_available_extensions
WHERE name = 'pg_stat_statements';
-- Run the upgrade (executes the delta SQL script, e.g. pg_stat_statements--1.9--1.10.sql)ALTEREXTENSION pg_stat_statements UPDATE; -- updates to latestALTEREXTENSION pg_stat_statements UPDATETO '1.10'; -- pin to specific version-- STEP 5: Safe removal — CASCADE drops all dependent objects too-- Without CASCADE, DROP fails if any user object depends on extension typesDROPEXTENSIONIFEXISTS pg_stat_statements CASCADE;
-- Confirm it's goneSELECTCOUNT(*) AS remaining_installations
FROM pg_extension
WHERE extname = 'pg_stat_statements';
On streaming replication setups, the OS package containing the extension's .so file must be installed on every replica before you run CREATE EXTENSION on the primary. WAL replay on the standby will attempt to load the .so and crash the replica process with 'could not load library' if it's missing — causing replication lag or a full replica reset.
Production Insight
The separation between OS package upgrade and ALTER EXTENSION UPDATE is a common source of production outages.
Never assume a package update upgrades the extension in the database.
Rule: automate both steps in tandem — deploy package, then run ALTER EXTENSION UPDATE as a SQL migration.
Key Takeaway
shared_preload_libraries is a silent failure trap.
If an extension requires it and it's missing, CREATE EXTENSION works but the extension does nothing.
Always verify with a functional test — not just a successful DDL.
Three Extensions You Should Know Deeply — pgvector, PostGIS, and pg_partman
Knowing how to run CREATE EXTENSION is table stakes. Knowing the performance model and operational nuances of specific extensions is what separates a database engineer from someone who just read the docs.
pgvector adds vector data types and approximate nearest-neighbour search, making Postgres a viable store for AI embedding search. Its HNSW index (added in 0.5.0) dramatically outperforms the older IVFFlat index for most workloads, but HNSW builds are memory-intensive — each connection building the index uses maintenance_work_mem, and building in parallel multiplies that.
PostGIS is the gold standard for geospatial work, but it adds two extension layers: postgis (core) and optionally postgis_topology and postgis_raster. The ST_DWithin function with a geography (not geometry) column correctly handles great-circle distance but is ~10x slower than geometry unless you have a spatial index on the column.
pg_partman automates partition maintenance — creating future partitions and dropping old ones on a schedule. It runs as background worker processes and requires pg_cron or a similar scheduler. The critical gotcha: pg_partman won't automatically attach data inserted into the parent table to the correct child partition unless you also configure partition_data correctly. Orphaned rows in the parent table silently kill query performance.
pgvector_hnsw_production.sqlSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
-- ============================================================-- pgvector: store OpenAI embeddings and do similarity search-- with an HNSW index tuned for production recall vs speed-- ============================================================CREATEEXTENSIONIFNOTEXISTS vector; -- installs the vector type and operators-- Table storing article embeddings from a text-embedding-3-small model-- (1536 dimensions for OpenAI's small model)CREATETABLEarticle_embeddings (
article_id BIGINTPRIMARYKEY,
title TEXTNOTNULL,
content_snippet TEXTNOTNULL,
embedding vector(1536) NOTNULL, -- the actual float array
embedded_at TIMESTAMPTZNOTNULLDEFAULTNOW()
);
-- Build an HNSW index.-- m = max connections per node (higher = better recall, more RAM)-- ef_construction = build-time search width (higher = better recall, slower build)-- These values are a production starting point; tune with recall benchmarks.CREATEINDEX article_embeddings_hnsw_idx
ON article_embeddings
USINGhnsw (embedding vector_cosine_ops) -- cosine similarity for NLP embeddingsWITH (
m = 16, -- default; go up to 64 for high-recall use cases
ef_construction = 128-- default 64; doubling improves recall ~2-5%
);
-- At query time, set ef_search to control recall vs speed tradeoff-- This is a per-session setting — set it in your app's connection pool setupSET hnsw.ef_search = 100; -- default 40; higher = better recall, slower query-- Find the 5 most semantically similar articles to a given embedding-- '[0.12, -0.34, ...]' would be your query vector from the embedding modelWITH query_vector AS (
-- In practice this comes from your application layer as a parameterSELECT '[0.021, 0.043, -0.117, 0.089]'::vector(4) AS vec -- toy 4-dim example
)
SELECT
ae.article_id,
ae.title,
-- <=> is the cosine distance operator; 1 - distance = cosine similarity1 - (ae.embedding <=> qv.vec) AS cosine_similarity,
ae.content_snippet
FROM article_embeddings ae
CROSSJOIN query_vector qv
ORDERBY ae.embedding <=> qv.vec -- ORDER BY distance ASC = most similar firstLIMIT5;
-- Monitor index build progress (for large tables, HNSW build can take minutes)SELECT
phase,
blocks_done,
blocks_total,
ROUND(100.0 * blocks_done / NULLIF(blocks_total, 0), 1) AS pct_complete
FROM pg_stat_progress_create_index
WHERE relid = 'article_embeddings'::regclass;
Output
article_id | title | cosine_similarity | content_snippet
For pgvector HNSW indexes, set max_parallel_maintenance_workers = 4 and a generous maintenance_work_mem (e.g., 2GB) before building the index on large datasets. HNSW index builds are single-threaded per index, but the memory budget directly controls build quality. After the index is built, reset maintenance_work_mem to avoid memory pressure during normal operations.
Production Insight
pgvector's HNSW index build can exhaust maintenance_work_mem on large tables — monitor pg_stat_progress_create_index.
If the build fails with 'out of memory', reduce ef_construction or increase maintenance_work_mem.
Rule: benchmark recall vs speed with your own data — don't trust docs default values blindly.
Key Takeaway
HNSW gives near-exact recall but costs memory during build and larger disk footprint.
IVFFlat is faster to build and cheaper — right for frequent re-indexing.
Choose based on your query latency budget, not just recall numbers.
Building a Custom PostgreSQL Extension from Scratch
Building your own extension demystifies every extension you'll ever use and opens the door to organisation-specific functionality you can version, test, and deploy just like application code.
A minimal extension needs exactly three files: a control file (name.control), a SQL installation script (name--version.sql), and optionally a C file compiled to a shared object for performance-critical or type-level functionality. Pure SQL extensions are fully portable and need no compilation — they're underused and underappreciated.
The control file specifies the extension's identity: its default version, whether it's relocatable, what schema it prefers, and which other extensions it depends on. The requires field is how Postgres enforces extension dependency ordering — if your extension depends on uuid-ossp, Postgres will refuse to install yours without it.
The SQL script runs with the privileges of the user calling CREATE EXTENSION, inside a transaction. If any statement fails, the whole installation rolls back — a beautiful guarantee. Objects created in the script are automatically tagged as extension-owned in pg_depend, so you don't need to manage that yourself.
For production custom extensions, store them in a git repo, use PGXS (the extension build system that ships with PostgreSQL) to compile and install, and write pgTAP tests against your install/upgrade/uninstall scripts before they touch any real cluster.
build_custom_extension.shBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
#!/usr/bin/env bash
# ============================================================
# Build a pure-SQL custom extension called 'safemath'
# that provides overflow-safe integer arithmetic helpers.
# No C compilation needed — pure SQL extensions are portable.
# ============================================================
set -euo pipefail
EXT_NAME="safemath"
EXT_VERSION="1.0"
# Find where PostgreSQL expects extension files
PG_SHAREDIR=$(pg_config --sharedir)
PG_EXTDIR="${PG_SHAREDIR}/extension"
echo "Installing ${EXT_NAME} to ${PG_EXTDIR}"
# ---- FILE1: Control file ----
# This is what PostgreSQL reads when you call CREATEEXTENSION safemath
cat > "/tmp/${EXT_NAME}.control" << 'EOF'
# safemath extension
default_version = '1.0'
relocatable = true
schema = safemath
comment = 'Overflow-safe arithmetic functions for financial calculations'EOF
# ---- FILE2: SQL installation script ----
# Named exactly: extname--version.sql (double dash is required)
cat > "/tmp/${EXT_NAME}--${EXT_VERSION}.sql" << 'EOF'
-- SQL script runs inside a transaction during CREATEEXTENSION
-- The @extschema@ placeholder is replaced by the schema Postgres chose
-- Safe addition: returns NULL instead of overflowing
CREATEORREPLACEFUNCTION @extschema@.safe_add(
addend_a BIGINT,
addend_b BIGINT
)
RETURNSBIGINTLANGUAGE plpgsql
IMMUTABLESTRICTPARALLELSAFE -- PARALLELSAFE lets planner use this in parallel queries
AS $$
BEGIN
-- pg_catalog.int8 max is 9223372036854775807
-- Checkfor overflow before it happens to avoid exception handling overhead
IF addend_b > 0AND addend_a > (9223372036854775807 - addend_b) THENRETURNNULL; -- would overflow positive
ENDIF;
IF addend_b < 0AND addend_a < (-9223372036854775808 - addend_b) THENRETURNNULL; -- would overflow negative
ENDIF;
RETURN addend_a + addend_b;
END;
$$;
-- Safe multiply with the same NULL-on-overflow contract
CREATEORREPLACEFUNCTION @extschema@.safe_multiply(
factor_a BIGINT,
factor_b BIGINT
)
RETURNSBIGINTLANGUAGE sql
IMMUTABLESTRICTPARALLELSAFEAS $$
SELECTCASEWHEN factor_b = 0THEN0WHENABS(factor_a) > (9223372036854775807 / ABS(factor_b)) THENNULLELSE factor_a * factor_b
END;
$$;
-- Useful view: show current extension version at runtime
CREATEVIEW @extschema@.extension_info ASSELECT
extname AS name,
extversion AS version
FROM pg_extension
WHERE extname = 'safemath';
EOF
# Copy files to where PostgreSQL can find them
sudo cp "/tmp/${EXT_NAME}.control""${PG_EXTDIR}/"
sudo cp "/tmp/${EXT_NAME}--${EXT_VERSION}.sql""${PG_EXTDIR}/"
echo "Files installed. Now run in psql:"
echo " CREATE EXTENSION safemath;"
echo " SELECT safemath.safe_add(9223372036854775800, 100); -- should return NULL"
Output
Installing safemath to /usr/share/postgresql/16/extension
Files installed. Now run in psql:
CREATE EXTENSION safemath;
SELECT safemath.safe_add(9223372036854775800, 100); -- should return NULL
Interview Gold:
The @extschema@ placeholder is substituted at install time by PostgreSQL's extension loader — it's not a SQL variable. This is why relocatable extensions work: the schema name is baked into function definitions at CREATE EXTENSION time, not hardcoded in the script. Interviewers love this question because most devs have never looked at an extension SQL file.
Production Insight
A failed custom extension install due to a syntax error can leave partial objects — always test in a disposable database.
Use pgTAP to test install/upgrade/uninstall scripts before deployment.
Rule: version your extension control file and SQL scripts in git; tag releases with semantic versions.
Key Takeaway
The @extschema@ placeholder is substituted at install time.
That's how relocatable extensions work — schema name is baked in at CREATE EXTENSION time.
Never hardcode schema names in extension SQL scripts.
Extension Security and Permission Models — The Defensive Side
Extensions run inside the database backend — no sandbox, no isolation. That means a malicious or buggy extension can read any data the backend can access, including memory of other connections. PostgreSQL's trust model relies on the superuser installing extensions, but after installation, the objects are owned by the superuser by default. However, any user can call extension functions if they have EXECUTE privilege, unless you revoke it.
For extensions like pg_stat_statements that expose performance data, the reset function is dangerous — any user can wipe hours of monitoring data if you don't revoke PUBLIC access. For extensions that create new data types (like pgvector or PostGIS), columns of those types can be accessed by any user if the table's permissions allow.
The safest pattern: install non-relocatable extensions in a dedicated schema, revoke all privileges from PUBLIC on extension functions, and grant only to specific roles. For relocatable extensions, use the SCHEMA option to isolate them. Always audit with \dp+ and check function permissions.
Also consider that extensions can introduce background workers (like pg_partman). These workers run with the privileges of the user who configured them — if that user is a superuser, the worker has full access. Limit background worker privileges to only what's needed.
extension_security_audit.sqlSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
-- ============================================================-- Audit extension privileges and lock down dangerous functions-- ============================================================-- 1. List all extension functions with their privilegesSELECT
n.nspname AS schema,
p.proname AS function_name,
pg_catalog.pg_get_function_identity_arguments(p.oid) AS args,
pg_catalog.array_agg(
CASEWHEN aclitem[1] ISNULLTHEN'PUBLIC'ELSE aclitem[1]::text
END
) AS granted_to
FROM pg_proc p
JOIN pg_namespace n ON n.oid = p.pronamespace
LEFTJOIN pg_depend d ON d.objid = p.oid AND d.deptype = 'e'WHERE d.refclassid = 'pg_extension'::regclass
GROUPBY n.nspname, p.proname, p.oid;
-- 2. Revoke EXECUTE on pg_stat_statements_reset() from PUBLICREVOKEALLONFUNCTIONpg_stat_statements_reset() FROMPUBLIC;
-- 3. Grant only to monitoring_role (create the role first if needed)CREATEROLE monitoring_role;
GRANTEXECUTEONFUNCTIONpg_stat_statements_reset() TO monitoring_role;
-- 4. Check for extensions that have background workers consuming max_worker_processesSELECT
extname,
extversion,
pg_catalog.pg_stat_activity.pid,
pg_catalog.pg_stat_activity.state
FROM pg_extension
LEFTJOIN pg_stat_activity ON pg_stat_activity.query LIKE'%' || extname || '%'WHERE extname IN ('pg_partman', 'pg_cron', 'pg_prewarm');
-- 5. Verify that no extension-owned table has unwanted grantsSELECT
schemaname,
tablename,
array_agg(privilege_type) AS privileges_granted
FROM pg_tables
JOIN pg_depend ON pg_depend.objid = (pg_tables.schemaname || '.' || pg_tables.tablename)::regclass
WHERE deptype = 'e'ANDhas_table_privilege('public', pg_tables.schemaname || '.' || pg_tables.tablename, 'SELECT')
GROUPBY schemaname, tablename;
public | pg_stat_statements_reset | oid,oid,bigint | {PUBLIC}
public | pg_stat_statements_info | | {PUBLIC}
(2 rows)
-- After REVOKE:
schema | function_name | granted_to
--------+-------------------------+--------------
public | pg_stat_statements_reset | {monitoring_role}
(1 row)
Mental Model: Extensions as Library Extensions
Any extension function you grant to PUBLIC can be called by any database user — no sandboxing.
Background workers (pg_partman, pg_cron) run as the role that configured them — if that's a superuser, they have full access.
Revoke EXECUTE on dangerous functions like reset() immediately after CREATE EXTENSION.
Install extensions in dedicated schemas to namespace their objects and control search_path access.
Audit extension object permissions regularly with queries against pg_depend and pg_proc.
Production Insight
A background worker from an extension running as superuser can be exploited if the extension has a vulnerability.
Limit background worker privileges by creating a dedicated role that owns only the necessary schema.
Rule: never let extension background workers run as superuser — create a restricted role for them.
Key Takeaway
Extensions run in the same memory space as PostgreSQL — no sandbox.
Revoke dangerous function access from PUBLIC immediately after install.
Audit extension permissions with pg_depend and pg_proc.
● Production incidentPOST-MORTEMseverity: high
Replica Crash After Installing pg_stat_statements
Symptom
After running CREATE EXTENSION pg_stat_statements on the primary, the streaming replica disconnected and its logs showed: 'ERROR: could not load library /usr/lib/postgresql/16/lib/pg_stat_statements.so: No such file or directory'. Replication lag spiked to infinity.
Assumption
The team assumed extension SQL scripts are replicated and applied on the standby automatically, and that the shared library would be present because they installed it on all nodes.
Root cause
The key insight: CREATE EXTENSION is replicated via WAL. When the standby replays the WAL record, it tries to load the .so file via dlopen(). If that file doesn't exist on the standby's filesystem, the standby backend crashes and the WAL replay stops. The team had only installed the postgresql-16-pg-stat-statements package on the primary.
Fix
Install the extension OS package on every replica and the primary before running CREATE EXTENSION. For existing clusters with the package missing on replicas, install the package and restart the standby (or use pg_ctl promote if it's already broken).
Key lesson
Always install extension OS packages on all cluster nodes before running CREATE EXTENSION on the primary.
Treat the .so file deployment as a prerequisite in your runbook — not an afterthought.
After installing a new extension, verify replication health with SELECT pg_is_in_recovery() and check pg_stat_replication for lag.
Production debug guideSymptom → Action guide for the four most common extension failures in production4 entries
Symptom · 01
CREATE EXTENSION succeeds but extension functions return empty results or no rows
→
Fix
Check if the extension requires shared_preload_libraries. Verify by SELECT name, pending_restart FROM pg_settings WHERE name = 'shared_preload_libraries'. If missing, add it, restart, then re-test.
Symptom · 02
ALTER EXTENSION UPDATE fails with 'could not open extension control file'
→
Fix
The OS package hasn't been updated. Run apt update && apt upgrade on all nodes first, then re-run ALTER EXTENSION. Verify new .sql files in SHAREDIR/extension/.
Symptom · 03
Search_path errors: function not found even though extension is installed
→
Fix
Run SELECT extname, nspname FROM pg_extension JOIN pg_namespace ON extnamespace = pg_namespace.oid. Add the extension's schema to your search_path with SET search_path TO public, <ext_schema>;.
Symptom · 04
Replica crashes after CREATE EXTENSION on primary
→
Fix
The .so file is missing on the standby. Install the OS package on all replicas. If the standby is already broken, reinitialize it from the primary using pg_basebackup.
★ Quick Extension Debug Cheat SheetUse these commands when an extension misbehaves — no theory, just the fix.
Extension doesn't show data (empty views)−
Immediate action
Check shared_preload_libraries
Commands
SELECT name, setting, pending_restart FROM pg_settings WHERE name = 'shared_preload_libraries';
If missing: ALTER SYSTEM SET shared_preload_libraries = 'pg_stat_statements'; then restart cluster.
Fix now
Restart the cluster after ALTER SYSTEM SET. Verify with SELECT calls FROM pg_stat_statements LIMIT 1;
Extension upgrade fails+
Immediate action
Check package version vs installed version
Commands
SELECT name, installed_version, default_version FROM pg_available_extensions WHERE name = 'your_ext';
apt list --upgradable | grep postgresql
Fix now
apt upgrade on all nodes, then ALTER EXTENSION your_ext UPDATE;
Function not found error+
Immediate action
Check search_path and schema
Commands
SHOW search_path;
SELECT extname, nspname FROM pg_extension JOIN pg_namespace ON extnamespace = pg_namespace.oid;
Fix now
SET search_path TO public, <extension_schema>; or qualify function calls with schema.
Replica crash after extension install+
Immediate action
Check standby logs for missing library error
Commands
On standby: tail -100 /var/log/postgresql/postgresql-16-main.log | grep 'could not load library'
Verify .so file on standby: ls /usr/lib/postgresql/16/lib/ | grep <extension>
Fix now
Install OS package on standby, then restart standby or reinitialize.
IVFFlat vs HNSW Index in pgvector
Aspect
IVFFlat Index (pgvector)
HNSW Index (pgvector)
Build time
Fast — minutes for millions of rows
Slow — can take hours for millions of rows
Query recall at k=10
~90-95% (tunable via probes)
~97-99% (tunable via ef_search)
Memory during build
Low — uses work_mem
High — uses maintenance_work_mem per connection
Memory at query time
Low — index is disk-resident
Higher — upper graph layers cached in shared_buffers
Requires row count for build
Yes — must INSERT data first, then CREATE INDEX
No — can build on empty table, rows added incrementally
Index size on disk
Smaller
Larger (~2-3x IVFFlat for same dataset)
Best use case
Batch workloads, frequently re-built indexes
Production similarity search requiring high recall
Available since pgvector
0.4.0
0.5.0 (late 2023)
Key takeaways
1
pg_depend is the source of truth
every object an extension creates is registered there, which is why DROP EXTENSION CASCADE is safe and why you can't accidentally lose extension-owned objects without explicitly dropping the extension.
2
shared_preload_libraries is a silent failure trap
if an extension requires it and it's missing, CREATE EXTENSION works but the extension does nothing, with no error raised. Always verify with a functional test, not just a successful DDL.
3
The OS package upgrade and ALTER EXTENSION UPDATE are two separate, ordered steps
skipping either one leaves your cluster in an inconsistent state where the database version and the binary on disk disagree.
4
HNSW indexes in pgvector give you near-exact recall but cost significant memory at build time and larger index size on disk
IVFFlat is faster to build and cheaper, making it the right choice for workloads where you re-index frequently or have tight memory budgets.
5
Revoke PUBLIC access on extension functions immediately after install
especially reset/delete functions — to prevent accidental data loss or performance degradation.
Common mistakes to avoid
4 patterns
×
Forgetting shared_preload_libraries for extensions that need it
Symptom
CREATE EXTENSION succeeds with no error, but pg_stat_statements shows empty results or pg_prewarm does nothing. No warning is raised.
Fix
Check the extension docs for 'requires preloading', add the extension name to shared_preload_libraries via ALTER SYSTEM SET, then restart the cluster. Verify with SELECT * FROM pg_settings WHERE name = 'shared_preload_libraries'.
×
Running ALTER EXTENSION UPDATE without first updating the OS package
Symptom
ALTER EXTENSION name UPDATE fails with 'could not open extension control file' or executes but the new .so file is missing, causing function calls to crash with 'invalid memory alloc request'.
Fix
Always follow the order: (1) apt/yum upgrade the Postgres extension package on every node, (2) then run ALTER EXTENSION UPDATE in SQL. Treat the two steps as an atomic deployment unit in your runbook.
×
Installing extensions into the public schema and granting broad access
Symptom
Any user with CONNECT privilege can call dangerous functions like pg_stat_statements_reset(), wiping monitoring data, or PostGIS functions that are computationally expensive.
Fix
Install relocatable extensions into a dedicated schema (CREATE EXTENSION postgis SCHEMA geo;), set search_path explicitly for application roles, and use REVOKE ALL ON FUNCTION ... FROM PUBLIC followed by targeted GRANTs. For non-relocatable extensions, use REVOKE immediately after CREATE EXTENSION.
×
Building an HNSW index without adjusting maintenance_work_mem
Symptom
Index build fails with 'out of memory' or runs extremely slowly because the default maintenance_work_mem (64MB) is too low for large datasets.
Fix
Set maintenance_work_mem to at least 2GB in the session before building the HNSW index. Monitor build progress with pg_stat_progress_create_index. After build, reset maintenance_work_mem to default.
INTERVIEW PREP · PRACTICE MODE
Interview Questions on This Topic
Q01SENIOR
What's the difference between CREATE EXTENSION and simply running the ex...
Q02SENIOR
If a PostgreSQL replica keeps crashing after you installed a new extensi...
Q03SENIOR
You've upgraded the PostGIS OS package from 3.3 to 3.4 on all nodes. A c...
Q01 of 03SENIOR
What's the difference between CREATE EXTENSION and simply running the extension's SQL script manually — and why does it matter for schema management?
ANSWER
CREATE EXTENSION automates three things: (1) reads the .control file to determine version, dependencies, and schema, (2) runs the SQL installation script inside a transaction so failure rolls back everything, and (3) registers all created objects in pg_depend with deptype 'e'. This means DROP EXTENSION CASCADE can safely remove all extension-owned objects. Running the SQL script manually would create objects but Postgres wouldn't associate them with an extension, so DROP EXTENSION wouldn't clean them up — you'd need to track and drop each object individually. For schema management, extension ownership guarantees that upgrades and removals are safe and reversible.
Q02 of 03SENIOR
If a PostgreSQL replica keeps crashing after you installed a new extension on the primary, what are the three most likely causes and how would you diagnose each?
ANSWER
Three causes: (1) The OS package containing the .so file is missing on the replica — look for 'could not load library' in the standby log. Fix: install the package and restart the standby. (2) The extension creates a new operator or data type that conflicts with an existing object on the replica — check for duplicate object errors in standby logs. Fix: rename or drop conflicting objects before CREATE EXTENSION. (3) The extension modifies system catalogs that aren't expected on the standby — less common, but check for 'cache lookup failed' errors. Fix: consult extension documentation; some extensions require special handling for replicas. Diagnosis starts with tailing the standby log immediately after the primary installation.
Q03 of 03SENIOR
You've upgraded the PostGIS OS package from 3.3 to 3.4 on all nodes. A colleague says the upgrade is done. What's wrong with that statement, and what steps are still required?
ANSWER
The OS package upgrade only updates the files on disk — the .so and new SQL scripts. The database still runs the old version (3.3) of the extension. You must run ALTER EXTENSION postgis UPDATE; to apply the delta SQL script which modifies the extension's objects to the new version. Skipping this step leaves the extension in an inconsistent state: the binary is new, but the database catalog still references old function signatures, which can cause runtime errors. The complete workflow: (1) upgrade OS package on all nodes, (2) run ALTER EXTENSION UPDATE on the primary (it will replicate to replicas), (3) verify with SELECT extversion FROM pg_extension WHERE extname = 'postgis';.
01
What's the difference between CREATE EXTENSION and simply running the extension's SQL script manually — and why does it matter for schema management?
SENIOR
02
If a PostgreSQL replica keeps crashing after you installed a new extension on the primary, what are the three most likely causes and how would you diagnose each?
SENIOR
03
You've upgraded the PostGIS OS package from 3.3 to 3.4 on all nodes. A colleague says the upgrade is done. What's wrong with that statement, and what steps are still required?
SENIOR
FAQ · 4 QUESTIONS
Frequently Asked Questions
01
Can I install PostgreSQL extensions without superuser privileges?
Not by default. CREATE EXTENSION requires superuser or, in PostgreSQL 13+, a role with the pg_extension_owner membership if the extension is marked trusted in its control file. On managed cloud platforms like AWS RDS, you use the rds_superuser role which has pre-approved extension permissions but cannot install arbitrary extensions outside the allowed list.
Was this helpful?
02
Does installing an extension affect PostgreSQL performance even if I never use it?
For most extensions, no — the shared object is only loaded into a backend process via dlopen() when a function from that extension is first called. However, extensions that use background workers (pg_partman, pg_cron) consume a worker slot from max_worker_processes at all times once installed and configured, which can starve autovacuum or parallel query workers on busy clusters.
Was this helpful?
03
What happens to my data if I DROP EXTENSION with CASCADE?
Any column using a type defined by the extension (e.g., a vector column from pgvector, or a geometry column from PostGIS) will be dropped along with the extension. CASCADE is not just a cleanup tool — it's a destructive operation on user data. Always audit with SELECT * FROM pg_depend WHERE refobjid = (SELECT oid FROM pg_extension WHERE extname = 'your_extension') before running DROP EXTENSION CASCADE in production.
Was this helpful?
04
How do I move an extension to a different schema after installation?
Only relocatable extensions (extrelocatable = true) can be moved after installation using ALTER EXTENSION name SET SCHEMA new_schema. For non-relocatable extensions, you must drop and recreate the extension in the desired schema. Check extrelocatable in pg_extension before planning schema layout.