Re: Reviving lost replication slots - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Reviving lost replication slots
Date
Msg-id CAA4eK1LuN2LMLi6sY6nF6Te2+4gOfp01w=WpJgyU3xYJWe4TtQ@mail.gmail.com
Whole thread Raw
In response to Re: Reviving lost replication slots  (sirisha chamarthi <sirichamarthi22@gmail.com>)
List pgsql-hackers
On Thu, Nov 10, 2022 at 4:07 PM sirisha chamarthi
<sirichamarthi22@gmail.com> wrote:
>
> On Wed, Nov 9, 2022 at 2:37 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> On Fri, Nov 4, 2022 at 1:40 PM sirisha chamarthi
>> <sirichamarthi22@gmail.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'tsee it being set to InvalidTransactionId in ReplicationSlotsComputeRequiredXmin. Attached a small patch to address
thisand 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.



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Typo about subxip in comments
Next
From: "wangw.fnst@fujitsu.com"
Date:
Subject: RE: Data is copied twice when specifying both child and parent table in publication