| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com> |
| Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, shveta malik <shveta(dot)malik(at)gmail(dot)com> |
| Subject: | Re: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber |
| Date: | 2026-08-06 09:12:36 |
| Message-ID: | CAA4eK1+wrmk5tz14H8TyzE3JE9LoKNJLfBn6kzUuK8rGQiAYJQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Aug 5, 2026 at 10:55 AM Zhijie Hou (Fujitsu)
<houzj(dot)fnst(at)fujitsu(dot)com> wrote:
>
> 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)).
>
The patch looks good to me, so I pushed.
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | solai v | 2026-08-06 09:40:08 | Re: Cleaning up PREPARE query strings? |
| Previous Message | Andrey Borodin | 2026-08-06 09:07:19 | Re: Restructured Shared Buffer Hash Table |