On v2, I see a deadlock because v2 locks the table first and then the
schema (a bottom-up approach). IIUC, this is the inverse order of
other commands, which take locks top-down (schema first, then table).
I think there could also be other such scenarios too that can
reproduce deadlock with v2. See this testcase:
CREATE SCHEMA test_schema;
CREATE TABLE test_schema.test_table (id int, val int);
INSERT INTO test_schema.test_table VALUES (1, 1);
Session A:
BEGIN;
--RowShareLock on table, just to make session B wait
SELECT * FROM test_schema.test_table FOR UPDATE;
Session B:
BEGIN;
-- Acquires AccessExclusiveLock on the schema.
-- Then blocks trying to lock the table, waiting on Session A.
DROP SCHEMA test_schema CASCADE;
Session A:
-- Upgrades table lock to RowExclusiveLock.
-- CheckCmdReplicaIdentity() then attempts to lock the schema.
UPDATE test_schema.test_table SET val = 2;
UPDATE fails with:
ERROR: deadlock detected
DETAIL: Process 20101 waits for RowExclusiveLock on object 16384 of
class 2615 of database 5; blocked by process 20115.
Process 20115 waits for AccessExclusiveLock on relation 16385 of
database 5; blocked by process 20101.
HINT: See server log for query details.
thanks
Shveta
