| From: | Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com> |
|---|---|
| To: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
| Cc: | vignesh C <vignesh21(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com> |
| Subject: | Re: Parallel Apply |
| Date: | 2026-10-07 11:19:01 |
| Message-ID: | CANhcyEVraxytmJpbTMF+yYWOy86LKZ4s=A0K+g7ygow8hFkK_w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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
| Attachment | Content-Type | Size |
|---|---|---|
| sub.log | application/octet-stream | 2.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2026-10-07 11:43:03 | Re: REPACK (CONCURRENTLY) can't complete after ~105M concurrent updates/deletes |
| Previous Message | Shubhra Jain | 2026-10-07 11:04:00 | Re: Do we want to avoid checksumming extra files in the datadir? [was: BUG #19647] |