| 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-05 06:02:16 |
| Message-ID: | CAA4eK1K+xf=n_wRv6MFYiAh+_if9_Czr5jWKim3LKLMSSKaohw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Nov 4, 2022 at 1:40 PM sirisha chamarthi
<sirichamarthi22(at)gmail(dot)com> wrote:
>
> A replication slot can be lost when a subscriber is not able to catch up with the load on the primary and the WAL to catch up exceeds max_slot_wal_keep_size. When this happens, target has to be reseeded (pg_dump) from the scratch and this can take longer. I am investigating the options to revive a lost slot.
>
Why in the first place one has to set max_slot_wal_keep_size if they
care for WAL more than that? If you have a case where you want to
handle this case for some particular slot (where you are okay with the
invalidation of other slots exceeding max_slot_wal_keep_size) then the
other possibility could be to have a similar variable at the slot
level but not sure if that is a good idea because you haven't
presented any such case.
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Corey Huinker | 2022-11-05 06:34:47 | Re: psql: Add command to use extended query protocol |
| Previous Message | John Naylor | 2022-11-05 05:54:18 | Re: remap the .text segment into huge pages at run time |