We also fix many extensions that lack active maintenance. The last release date for some of them was years ago. But PostgreSQL major version changes still affect them. Usually the original author writes version branches to handle different PG majors. If the extension is no longer maintained, a packager has to step in. We've talked about how this work helps the first three groups — users, authors, vendors. Can it also be useful to Postgres hackers? I think build coverage is a useful signal. When a patch breaks N extensions, that number is information. It shows ecosystem impact. This is where delivery infrastructure starts to look like feedback infrastructure.

Part IV Maintenance in the Wild

API Break

PIGSTY
Build failures cluster by moving PostgreSQL internals. When several extensions fail on the same surface, that is ecosystem impact data.
PG16 / PG17

Header and Datum internals

varatt.h, varlena macros, UUID Datum assumptions

Affected age pg_zstd pg_emailaddr acl
PG17

Executor and SRF helpers

tuplestore_donestoring and old materialized SRF paths

Affected pg_savior pgnodemx plprofiler system_stats
PG17

Planner and FDW contracts

FDW/custom scan pushdown and planner path API changes

Affected kafka_fdw citus postgres_fdw
PG18

Struct, annotation, and catalog details

TupleDesc, pg_noreturn, and system view dependencies

Affected pg_fsql pg_variables pllua pg_statsinfo
One red build is maintenance. N red builds on the same symbol is signal.