Re: ReplicationSlotRelease() clobbers another backend's statusFlags entry

From: Vlad Lesin <vladlesin(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Subject: Re: ReplicationSlotRelease() clobbers another backend's statusFlags entry
Date: 2026-09-30 08:34:23
Message-ID: f98f541d-8adf-4144-9ba1-37b935e59dd6@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/30/26 4:21 AM, Michael Paquier wrote:

>> Regarding the test, I only used to reproduce the issue but not reviewed well,
>> because not sure it's aimed to be included. It may need more polish, i.e.,
>> advance_wal() has already been defined.
>
> Regarding this part, I am unconvinced that this is worth the cycles
> spent on. I am OK to be proved wrong, but for one the test assumes
> that we could crash, which is an anti-pattern with the fix in place
> because we don't crash once the status flags are not correctly
> filtered.

Without the fix, the test fails even without the asserts from the
v2-0002 patch.

--
Best regards,
Vlad

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ajit Awekar 2026-09-30 08:35:52 Re: Allow table AMs to define their own reloptions
Previous Message Vaibhav Dalvi 2026-09-30 08:21:16 remote_apply commit hangs when wal_receiver_status_interval = 0