Re: Reviving lost replication slots

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: sirisha chamarthi <sirichamarthi22(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Reviving lost replication slots
Date: 2022-11-11 05:36:32
Message-ID: CAA4eK1LuN2LMLi6sY6nF6Te2+4gOfp01w=WpJgyU3xYJWe4TtQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 10, 2022 at 4:07 PM sirisha chamarthi
<sirichamarthi22(at)gmail(dot)com> wrote:
>
> On Wed, Nov 9, 2022 at 2:37 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>
>> On Fri, Nov 4, 2022 at 1:40 PM sirisha chamarthi
>> <sirichamarthi22(at)gmail(dot)com> wrote:
>> >
>> Is the intent of setting restart_lsn to InvalidXLogRecPtr was to
>> disallow reviving the slot?
>> >
>>
>> I think the intent is to compute the correct value for
>> replicationSlotMinLSN as we use restart_lsn for it and using the
>> invalidated slot's restart_lsn value for it doesn't make sense.
>
>
> Correct. If a slot is invalidated (lost), then shouldn't we ignore the slot from computing the catalog_xmin? I don't see it being set to InvalidTransactionId in ReplicationSlotsComputeRequiredXmin. Attached a small patch to address this and the output after the patch is as shown below.
>

I think you forgot to attach the patch. However, I suggest you start a
separate thread for this because the patch you are talking about here
seems to be for an existing problem.

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message wangw.fnst@fujitsu.com 2022-11-11 05:43:10 RE: Data is copied twice when specifying both child and parent table in publication
Previous Message Julien Rouhaud 2022-11-11 05:33:13 Re: Typo about subxip in comments