From: | Amit Kapila <akapila(at)postgresql(dot)org> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Fix deadlock for multiple replicating truncates of the same tabl |
Date: | 2021-05-21 03:31:35 |
Message-ID: | E1ljvst-00074h-8e@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Fix deadlock for multiple replicating truncates of the same table.
While applying the truncate change, the logical apply worker acquires
RowExclusiveLock on the relation being truncated. This allowed truncate on
the relation at a time by two apply workers which lead to a deadlock. The
reason was that one of the workers after updating the pg_class tuple tries
to acquire SHARE lock on the relation and started to wait for the second
worker which has acquired RowExclusiveLock on the relation. And when the
second worker tries to update the pg_class tuple, it starts to wait for
the first worker which leads to a deadlock. Fix it by acquiring
AccessExclusiveLock on the relation before applying the truncate change as
we do for normal truncate operation.
Author: Peter Smith, test case by Haiying Tang
Reviewed-by: Dilip Kumar, Amit Kapila
Backpatch-through: 11
Discussion: https://postgr.es/m/CAHut+PsNm43p0jM+idTvWwiGZPcP0hGrHMPK9TOAkc+a4UpUqw@mail.gmail.com
Branch
------
REL_12_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/18c6242b7c6da78341b6745bc9b0bcbca20d556b
Modified Files
--------------
src/backend/replication/logical/worker.c | 5 +--
src/test/subscription/t/010_truncate.pl | 53 +++++++++++++++++++++++++++++++-
2 files changed, 55 insertions(+), 3 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2021-05-21 15:50:58 | pgsql: Put some psql documentation pieces back into alphabetical order |
Previous Message | Tom Lane | 2021-05-20 22:32:54 | pgsql: Avoid detoasting failure after COMMIT inside a plpgsql FOR loop. |