Query icon
Log icon
Exit icon
Assert icon
Pause icon
Loop icon
Queries icon
Webhook icon
Schedule icon

Rebuild PostgreSQL Indexes After a Collation Version Change

Fix a PostgreSQL collation version mismatch after an OS upgrade. Rebuild affected indexes concurrently after approval, then refresh and verify.

Categories
DataInfrastructure

PostgreSQL sorts text with rules from the operating system's C library or from ICU. When an OS or image upgrade changes those rules, indexes built with the old rules no longer match: queries can miss rows that are there, and unique indexes can let duplicates in. PostgreSQL only logs a "collation version mismatch" warning. This flow finds the affected indexes, rebuilds them after approval, and only then records the new collation version.

How it works

  1. The Webhook trigger starts a run from the upgrade pipeline. A weekly Schedule, shipped disabled, catches upgrades made by hand.
  2. drift compares the collation version PostgreSQL recorded with the one the system provides now, for the database and every collation in use. With no mismatch, stop_if_clean ends the run.
  3. precheck stops the run if an invalid index already exists, such as one left by an earlier failed rebuild.
  4. indexes lists every index whose key uses a changed collation, and plan logs them. approve waits for a DBA to resume the run, and cancels it after 24 hours.
  5. reindex rebuilds the indexes one at a time with REINDEX INDEX CONCURRENTLY, so writes continue.
  6. refresh runs ALTER DATABASE ... REFRESH COLLATION VERSION and ALTER COLLATION ... REFRESH VERSION, only after every rebuild succeeded.
  7. verify fails the run if a mismatch or an invalid index is left.

What you get

  • Indexes that match the new sort rules, rebuilt without blocking writes.
  • The warning cleared only after the indexes are fixed, never before.
  • A failed run naming the index, for example a unique index that now has duplicate keys.

Who it's for

  • DBAs and platform teams that upgrade the OS or PostgreSQL images under existing data.

Why orchestrate this with Kestra

The fix is an ordered sequence with a human decision in the middle. Kestra starts it from the upgrade pipeline, waits for approval, rebuilds one index at a time and keeps a history of what was rebuilt where.

Prerequisites

  • PostgreSQL 15 or later, and a superuser or the owner of the database, tables and collations.
  • Range-partitioned tables with a text partition key are not checked. Review them by hand.

Secrets

  • POSTGRES_USERNAME, POSTGRES_PASSWORD: the database login.
  • POSTGRES_COLLATION_WEBHOOK_KEY: the webhook key.

Quick start

  1. Add the secrets and set jdbc_url.
  2. Execute the flow after an upgrade, read the plan log and resume the run.
  3. Read the summary log. Run it once per database.

How to extend

  • Post the plan log to Slack before the pause.
  • Loop over every database of a cluster.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.