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.
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 |