0
0
Fork 1
mirror of https://mau.dev/maunium/synapse.git synced 2024-06-03 03:09:02 +02:00
synapse/synapse/storage/schema/main/delta/83/10_replica_identity_README.md
reivilibre 51e4e35653
Add a Postgres REPLICA IDENTITY to tables that do not have an implicit one. This should allow use of Postgres logical replication. (take 2, now with no added deadlocks!) (#16658)
* Add `ALTER TABLE ... REPLICA IDENTITY ...` for individual tables

We can't combine them into one file as it makes it likely to hit a deadlock

if Synapse is running, as it only takes one other transaction to access two

tables in a different order to the schema delta.

* Add notes

* Newsfile

Signed-off-by: Olivier Wilkinson (reivilibre) <oliverw@matrix.org>

* Re-introduce REPLICA IDENTITY test

---------

Signed-off-by: Olivier Wilkinson (reivilibre) <oliverw@matrix.org>
2023-12-04 14:57:28 +00:00

1 KiB

The 10_replica_identity_xxx.sql.postgres series of schema deltas adds replica identities for tables that do not have one implicitly as a result of having a primary key.

This is needed to use logical replication with Synapse (at least without UPDATE and DELETE statements failing!).

Where possible, we use an existing UNIQUE index on NOT NULL columns as the replica identity. Otherwise, we have to fall back to using the full row as a replica identity.

Unfortunately, by running all the ALTER TABLE statements in one schema delta per database, it was too likely to hit a deadlock as it would only take one other transaction from a running Synapse worker to access the tables out of order and trigger a deadlock.

By having each statement in its own delta file, each one is run in its own transaction and only needs to take a very brief (instant) lock on the table but no other tables, so there should be no chance of deadlock.

Like many schema deltas we already apply to Synapse, it is probably blocked by an ongoing pg_dump.