Re: Parallel Apply

Hi,

On Wed, Oct 7, 2026 at 7:19 PM Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com> wrote:
>
> > 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.

Thanks for reporting.

This is an existing issue that can happen without parallel mode as well. You
can execute the same steps after disabling parallel mode, and the apply worker
will get stuck while applying Transaction Q. So, it's not directly related to
parallel apply, we should handle it independently.

Best Regards,
Zhijie Hou