Re: Parallel Apply

On 17/09/2025 8:18 AM, Zhijie Hou (Fujitsu) wrote:
> I think debug_logical_replication_streaming=immediate differs from real parallel
> apply . It wasn't designed to simulate genuine parallel application because it
> restricts parallelism by requiring the leader to wait for each transaction to
> complete on commit. To achieve in-order parallel apply, each parallel apply
> worker should wait for the preceding transaction to finish, similar to the
> dependency wait in the current POC patch. We plan to extend the patch to support
> in-order parallel apply and will test its performance.

Will be interesting to see such results.
Actually, I have tried to improve parallelism in case of `debug_log And
debug_logical_replication_streaming=immediate` mode but faced with
deadlock issue: assume that T1 and T2 are updating the same tuples and
T1 is committed before T2 at publishers. If we let them execute in
parallel, then T2 can update the tuple first and T1 will wait end of T2.
But if we want to preserve commit order, we should not allow T2 to
commit before T1. And so we will get deadlock.

Certainly if we take in account dependencies between transactions (as in
your proposal), then we can avoid such situations. But I am not sure if
such deadlock can not happen even if there are conflicts between
transactions. Let's assume that T1 and T2 inserting some new records in
one table. Can index update in T2 cause obtaining some locks which
blocks T1? And T2 is not able to able to complete transaction and
release this locks because we want to commit T1 first.