PostgreSQL 19 RC1: the incompatible changes to test before GA on 19 November

The RC1 announcement is short and says so itself: “PostgreSQL 19 RC 1 will be mostly identical to the initial release of PostgreSQL 19, though some more fixes may be applied.” RC 2 is due on 12 November and general availability on 19 November 2026. The announcement does not list incompatibilities. The release notes do, and that is where the work is.

The changes that will bite

These are from the version 19 RC1 release notes as mirrored in pgEdge’s documentation. I list the ones I would test first.

JIT is now off by default. If you have analytical queries that quietly benefited from it, the plan will not change, but the timing might. Run your slowest reports once with SET jit = on and once without, and compare. On my local 18.6, SHOW jit says on, so this is a real default flip, not a no-op.

TOAST compression moves from pglz to lz4 through default_toast_compression. That is probably a win on size and speed, but it only applies to newly written values. Do not expect your existing tables to shrink.

RADIUS authentication is removed. The notes say PostgreSQL only supported RADIUS over UDP and treat it as unfixably insecure. If pg_hba.conf has a radius line anywhere, you need a different method before you upgrade.

Two smaller ones that cause real outages: standard_conforming_strings is forced on, so old dumps made with it off will not load into 19 or later, and max_locks_per_transaction doubles from 64 to 128, which changes the lock table size.

The one that stops pg_upgrade

The notes say the default index operator classes for inet and cidr change from btree_gist to GiST, because the btree_gist ones are broken and can leave out rows that should be returned. Upgrading a cluster that has such indexes is disallowed by pg_upgrade. So find them first.

SELECT n.nspname AS schema, c.relname AS index, a.attname AS column,
       t.typname AS type, oc.opcname AS opclass
FROM pg_index i
JOIN pg_class c ON c.oid = i.indexrelid
JOIN pg_namespace n ON n.oid = c.relnamespace
JOIN pg_am am ON am.oid = c.relam AND am.amname = 'gist'
JOIN LATERAL unnest(i.indkey::int2[], i.indclass::oid[]) AS k(attnum, opc) ON true
JOIN pg_opclass oc ON oc.oid = k.opc
JOIN pg_attribute a ON a.attrelid = i.indrelid AND a.attnum = k.attnum
JOIN pg_type t ON t.oid = a.atttypid
WHERE t.typname IN ('inet', 'cidr') AND oc.opcmethod = am.oid
  AND oc.opcname IN ('gist_inet_ops', 'gist_cidr_ops')
ORDER BY 1, 2;

I ran this on PostgreSQL 18.6 with the btree_gist extension installed. With one index using the core inet_ops and one using gist_inet_ops, it returned only the second. That is exactly the one the notes say will block you. I had no 19 build, so I could not run pg_upgrade itself.

And the feature people are excited about

The notes describe REPACK CONCURRENTLY as a way to rebuild tables without taking an access-exclusive lock. That is the headline for anyone who has scheduled a maintenance window around VACUUM FULL. I did not test it, there is no 19 binary on my machine, so I will not make claims about overhead or limits. Read the release notes section before you plan around it.

My test plan

1. Run the index query above on every database. Fix hits before anything else.
2. Grep pg_hba.conf for radius.
3. Replay a day of production queries against a copy and compare p95 with JIT off, then with it on for the heavy ones.
4. Check that every dump or restore script you own works with standard_conforming_strings = on.
5. Compare max_locks_per_transaction assumptions against shared memory settings.
6. Decide when you will upgrade. A major version at GA has fewer field reports than the first minor release, and I would not put a revenue database on it in the first week.

Sources & Credits

• PostgreSQL Global Development Group, “PostgreSQL 19 RC 1 Released!,” 15 October 2026: postgresql.org
• pgEdge documentation, PostgreSQL 19 RC1 release notes (incompatibilities section): docs.pgedge.com

The index query was run on PostgreSQL 18.6; the test plan and graphics are our own work. No PostgreSQL 19 build was available, so no behaviour of 19 itself was tested. Last verified 2026-10-30. Spotted a mistake? Tell us and we will correct it here with the date.