> Thanks for the contact. Here is an updated version. > > The version number now becomes v27 by the internal reviews. I adjusted each > patches to work well and pass tests, and fixed test codes to extract the > dependent transaction correctly.
Hi Kuroda-san, Hou-san, I was reviewing the 0008 patch and found that there can be a case of deadlock. Initial setup: Publisher: CREATE TABLE test_tab (id integer PRIMARY KEY, unique_value integer); INSERT INTO test_tab VALUES (1, 42); CREATE PUBLICATION pub1 FOR TABLE test_tab; Subscriber: CREATE TABLE test_tab (id integer PRIMARY KEY, unique_value integer); CREATE UNIQUE INDEX test_tab_local_unique_idx ON test_tab (unique_value); CREATE SUBSCRIPTION sub1 CONNECTION ... PUBLICATION regress_pub WITH (streaming = parallel, two_phase = on); Now the publisher has two sessions and executes in order to run: Session1: (Transaction P) BEGIN; DELETE FROM test_tab WHERE id = 1; PREPARE TRANSACTION 'regress_prepare'; Session2: (Transaction Q) INSERT INTO test_tab VALUES (2, 42); Session1: COMMIT PREPARED 'regress_prepare'; Transaction P is prepared on the subscriber and retains the locks. Transaction Q can commit to the publisher. But on the subscriber, Q's parallel apply worker is blocked while inserting (2, 42), waiting at 'ExecCheckIndexConstraints' and waiting for P's prepared transaction to release its locks. The leader then receives COMMIT PREPARED for P, which calls 'apply_handle_commit_prepared()' where 'maintain_commit_order_dependency(NULL);' is called. This makes the leader apply worker to wait for Q's parallel worker. So, parallel apply worker applying transaction Q is waiting for transaction P(on Subscriber) to release the locks. And Leader Apply Worker is waiting on Transaction Q to be applied to subscribers, creating a deadlock. ``` ps -ef | grep postgres | grep "apply worker" ubuntu 1268139 1268116 0 16:43 ? 00:00:00 postgres: logical replication apply worker for subscription 16391 waiting ubuntu 1268161 1268116 0 16:43 ? 00:00:00 postgres: logical replication parallel apply worker for subscription 16391 waiting ``` I have also attached the subscriber log for the same. Thanks, Shlok Kyal
sub.log
Description: Binary data
