Non-blocking writer barrier for publication table additions

Aperta
  • Qualcosa non va?
#4,788 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

@AbarnaaSree ci sta già lavorando.

Dal 28/8/2026.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
elixir, postgresql
Ambito
databases, distributed-systems

Direzione di ricerca

Inizia in Configurator intorno a do_publication_update(:add, …) e notify_filters_result(…, {:ok, :configured}), quindi segui la chiamata add_shape di Snapshotter e il suo timeout di 5 s. Decidi come coordinare tra questi percorsi una barriera per relazione e una deadline, inclusa la gestione delle partizioni se viene usato pg_locks. Il lavoro è completato quando i writer non vengono accodati, si attende l’insieme fisso di transazioni e i fallimenti per timeout rimangono ripetibili dopo i commit di ADD TABLE.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Non-blocking writer barrier for publication table additions

Follow-up to #4773 / the fix in Electric.Postgres.Configuration.add_table_to_publication/4 (wait_for_in_flight_writers/2).

Background

Logical decoding evaluates publication membership per change, against the catalog state at that point in the WAL. A transaction that wrote to a table before ALTER PUBLICATION … ADD TABLE committed never has those writes emitted by the replication stream, even if it commits after. They can only reach a shape through the initial snapshot, which only includes them if the writer has committed by the time the snapshot is taken.

The fix for #4773 closes that gap by taking LOCK TABLE … IN SHARE MODE inside the same transaction as the ADD TABLE. SHARE conflicts with the ROW EXCLUSIVE lock every writer holds until its transaction ends, so the addition can't commit — and waiting shapes can't start snapshotting — until every in-flight writer has finished. This mirrors what the ALTER TABLE … REPLICA IDENTITY FULL on the first-time-add path has always done implicitly through its ACCESS EXCLUSIVE lock. The wait is bounded by the configuration action timeout (5 s by default); on expiry the addition is rolled back and shape creation fails with a retryable error.

The side effect

SHARE is the weakest lock mode that conflicts with writers, but it also conflicts with SHARE UPDATE EXCLUSIVE, i.e. with VACUUM, ANALYZE, CREATE INDEX CONCURRENTLY, REINDEX CONCURRENTLY. While Electric's SHARE request is queued behind one of those, every new writer on the table queues behind Electric (Postgres makes new lock requests wait behind conflicting waiters to avoid starvation). Autovacuum cancels itself when it blocks a lock request (except anti-wraparound), but a manual VACUUM or a long CREATE INDEX CONCURRENTLY won't, so the outcome is:

  • shape creation on that table fails after the action timeout with table_lock_timeout;
  • each attempt stalls all writers on the table for up to that timeout;
  • clients retry, so a long-running maintenance operation turns into periodic write stalls for its duration.

The same holds for a genuinely long-running writer (a slow bulk load): shape creation is correctly blocked until it commits, but other writers on the table are stalled for the timeout on every attempt.

None of this is new to Electric — the first-time-add path has had it, with a stronger lock, since the replica identity change was introduced — but the #4773 fix makes it reachable on every re-add (after TRUNCATE invalidation, shape expiry, schema-change invalidation, etc.), not only the first time a table is synced.

Proposal

Replace the lock with a wait that blocks nobody. Immediately after ADD TABLE commits, capture the fixed set of transactions that could have written to the table before the commit, then poll until they have all ended before reporting the relation as configured:

  • exact: pg_locks rows with locktype = 'relation', relation = <oid> (plus partition oids for partitioned tables), mode RowExclusiveLock or stronger, keyed by virtualtransaction; or
  • simpler and slightly over-approximate: the xip_list of pg_current_snapshot() — only transactions that have written something have an xid, so idle read-only sessions are excluded, but writers on unrelated tables are not.

The set is fixed at capture time, so the wait can't starve under continuous write load, doesn't queue anyone, and needs no privilege beyond reading pg_locks.

What it needs

  • The natural place is the Configurator, between do_publication_update(:add, …) returning and notify_filters_result(…, {:ok, :configured}). The Configurator processes relation actions sequentially in one process, so a polling wait there would stall publication updates for every other table; it needs to become a per-relation task with its own deadline.
  • That deadline has to be coordinated with the add_shape call timeout in the Snapshotter (currently the 5 s GenServer.call default → SnapshotError.table_lock_timeout).
  • Partition enumeration for partitioned tables if the pg_locks variant is chosen.
  • The ADD TABLE transaction would then commit before the barrier, so the barrier failing (deadline) must leave the table published and the waiters failed-but-retryable, rather than roll the addition back as the current fix does.

When to do it

Not urgent. Pick it up if table_lock_timeout snapshot errors show up in telemetry at any meaningful rate, or if a user reports write stalls on a table during maintenance operations that correlate with shape creation.

Related

Separately from Electric, the same "write while unpublished, commit after ADD TABLE" transaction triggers a walsender relation-cache bug in PostgreSQL that drops later changes to the table until the next invalidation. It's fixed upstream (PG 18 commit 4909b38af0, back-patched to supported branches in the August 2025 minor releases — verify against the release notes). The Electric-side barrier doesn't cover it; the docs should recommend running a PG minor that includes the fix.

Lingua principale
TypeScript
Stelle
10.4k
Fork
399
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di electric-sql/electric

Tutte le issue di electric-sql/electric

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.