RE: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber

Hi,
On Wednesday, August 5, 2026 1:00 PM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
>
> Buildfarm animal olingo discovered a way to break this test, [1]:
> 400/402 subscription - postgresql:subscription/023_twophase_stream
> ERROR           230.82s   (exit status 255 or 0xff)
>
> pgsql.build/testrun/subscription/023_twophase_stream/log/023_twophase_s
> tream_subscriber.log
> ...
> That is, there is only one "ERROR:  logical replication parallel apply worker
> exited due to error" in the log, all the following errors are produced not by
> parallel worker, but by a leader worker...
>
> I'm able to reproduce this failure with:
> --- a/src/test/subscription/t/023_twophase_stream.pl
> +++ b/src/test/subscription/t/023_twophase_stream.pl
> @@ -445,2 +445,3 @@ $node_publisher->safe_psql(
>      INSERT INTO test_tab_2 values(2);
> +    SELECT pg_sleep(0.5);
>      PREPARE TRANSACTION 'xact';
>
> Could you have a look, please?

Thanks for reporting this. I confirmed that this is a race condition in the test
- the log offset is captured after the publisher's prepared transaction runs, so
the expected ERROR may have already been written before the offset was recorded.
This would cause the subsequent search to miss the message. To fix it, we can
simply get the offset before the prepared transaction runs.

The patch fixes the timeout on my machine (after adding the mentioned pg_sleep(0.5)).

Best Regards,
Zhijie Hou