A concrete case. I ran the build pipeline against PostgreSQL 19 development snapshots. Around 50 extensions failed to build. The failures cluster into a small set of categories — real API changes, old assumptions, missing version branches, dependency problems, and packages that were already fragile. Some hackers told me last year this might be useful for patches with broad reach — threading work, refactors, hook changes. If a CI pipeline can run extension builds against a patch series, the result could be useful input during patch review. I'd really like feedback from this room on whether that's worth pursuing. The goal is not to block progress. The goal is to make ecosystem impact visible earlier.

Part IV Maintenance in the Wild

PG 19 Compatibility

PIGSTY
PG19 build failures cluster. The signal points to a few header and API surfaces.
PG19 core change Confirmed examples
Transitive include cleanupexecnodes.h / tuptable.h
pgvectorpg_tracingsqlite_fdwfirebird_fdwpg_store_planspg_stat_monitor+16 more
Old typedef surface removedbits8 / bits16
q3cpg_similaritypg_roaringbitmappgfincorepg_arraymathlogical_ddlpg_filedump
Typed varlena helpersVARDATA / VARSIZE / SET_VARSIZE
hashtypespgpdflogin_hooksession_variabledecoder_rawdatasketchesspat
Hook signatures changedplanner / post_parse_analyze
pg_plan_filterpg_qospg_tracingpg_stat_monitorprovsqlpg_saviorage
Scan and FDW signatures changedtable_beginscan flags / disabled_nodes
pg_biscuitpgvectorpg_textsearchagesqlite_fdw
Executor instrumentation splitQueryDesc / InstrAlloc
pg_track_optimizerpg_store_planspg_tracingpg_stat_monitorsqlite_fdw
Focused internal API changesJsonb / DefineIndex / namespace / locale / headers
pgjqpg_net2pg_ivmprovsqlpg_bigmicu_extpgclone