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

From Bharath Rupireddy
Subject Re: Reviving lost replication slots
Date
Msg-id CALj2ACWK=QL37m=3x4UEtyURzOaLADh6QZEq120i6OCaeRFkAQ@mail.gmail.com
Whole thread Raw
In response to Re: Reviving lost replication slots  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Wed, Nov 9, 2022 at 3:53 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Nov 9, 2022 at 3:00 PM Bharath Rupireddy
> <bharath.rupireddyforpostgres@gmail.com> wrote:
> >
> > On Wed, Nov 9, 2022 at 2:02 PM Kyotaro Horiguchi
> > <horikyota.ntt@gmail.com> wrote:
> > >
> > > I don't think walsenders fetching segment from archive is totally
> > > stupid. With that feature, we can use fast and expensive but small
> > > storage for pg_wal, while avoiding replciation from dying even in
> > > emergency.
> >
> > It seems like a useful feature to have at least as an option and it
> > saves a lot of work - failovers, expensive rebuilds of
> > standbys/subscribers, manual interventions etc.
> >
> > If you're saying that even the walsedners serving logical replication
> > subscribers would go fetch from the archive location for the removed
> > WAL files, it mandates enabling archiving on the subscribers.
> >
>
> Why archiving on subscribers is required? Won't it be sufficient if
> that is enabled on the publisher where we have walsender?

Ugh. A typo. I meant it mandates enabling archiving on publishers.

-- 
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: heavily contended lwlocks with long wait queues scale badly
Next
From: Andrew Dunstan
Date:
Subject: Re: Small TAP improvements