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

From sirisha chamarthi
Subject Re: Reviving lost replication slots
Date
Msg-id CAKrAKeUUbO6KCpAS6stBbwgeNpNGOiFE31TPmbuP1iCi2zaFtQ@mail.gmail.com
Whole thread Raw
In response to Re: Reviving lost replication slots  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: Reviving lost replication slots
List pgsql-hackers


On Wed, Nov 9, 2022 at 12:32 AM 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.

Thanks! If there is a general agreement on this in this forum, I would like to start working on this patch,
 

At Tue, 8 Nov 2022 19:39:58 -0800, sirisha chamarthi <sirichamarthi22@gmail.com> wrote in
> > If it's a streaming replication slot, the standby will anyway jump to
> > archive mode ignoring the replication slot and the slot will never be
> > usable again unless somebody creates a new replication slot and
> > provides it to the standby for reuse.
> > If it's a logical replication slot, the subscriber will start to
> > diverge from the publisher and the slot will have to be revived
> > manually i.e. created again.
> >
>
> Physical slots can be revived with standby downloading the WAL from the
> archive directly. This patch is helpful for the logical slots.

However, supposing that WalSndSegmentOpen() fetches segments from
archive as the fallback and that succeeds, the slot can survive
missing WAL in pg_wal in the first place. So this patch doesn't seem
to be needed for the purpose.

Agree on this. If we add the proposed support, we don't need this patch.
 


regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

pgsql-hackers by date:

Previous
From: sirisha chamarthi
Date:
Subject: Re: Reviving lost replication slots
Next
From: Nikolay Shaplov
Date:
Subject: Re: TAP output format in pg_regress