Subscribes to the instance's db_channel Postgres notification channel and reloads the schema cache on PostgREST's reload signals (NOTIFY <db_channel>, 'reload schema').

Payloads

Mirroring PostgREST's listener:

• "reload schema" — re-run the DB introspection and atomically swap the instance's Bier.SchemaCache snapshot;
• "" (empty) — PostgREST reloads schema cache and config; Bier's config is host-supplied, so only the schema cache is reloaded;
• "reload config" — logged no-op (host applications own Bier's config);
• anything else — ignored with a debug log.

Bursts are coalesced: reload signals already queued in the mailbox are drained before a single reload runs, so a migration firing one NOTIFY per DDL statement causes one introspection, not N.

Connection ownership

The listener owns a dedicated Postgrex.Notifications connection (LISTEN cannot go through the request pool), started with auto_reconnect: false, and traps exits: when the connection drops — or cannot be established — the listener stays alive and retries with exponential backoff. A database outage therefore never crash-loops the instance's supervisor; reload signals just pause while the last good snapshot keeps serving.

Notifications sent while disconnected are lost, so after every re-connect the listener reloads unconditionally to catch up (PostgREST does the same). Only a clean first attempt skips that reload — the boot introspection has just run. A first connect that only succeeds after a retry reloads like any other reconnect, since NOTIFYs could have fired during the failed attempts in between.

A failed reload keeps the previous snapshot: Bier.SchemaCache.reload/1 only swaps after a fully successful introspection.