Re: Synchronizing slots from primary to standby - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Synchronizing slots from primary to standby
Date
Msg-id YgWH4/4tK1AMIOYG@momjian.us
Whole thread Raw
In response to Re: Synchronizing slots from primary to standby  (Ashutosh Sharma <ashu.coek88@gmail.com>)
Responses Re: Synchronizing slots from primary to standby  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
On Tue, Feb  8, 2022 at 08:27:32PM +0530, Ashutosh Sharma wrote:
> > Which means that if e.g. the standby_slot_names GUC differs from
> > synchronize_slot_names on the physical replica, the slots synchronized on the
> > physical replica are not going to be valid.  Or if the primary drops its
> > logical slots.
> >
> >
> > > Should the redo function for the drop replication slot have the capability
> > > to drop it on standby and its subscribers (if any) as well?
> >
> > Slots are not WAL logged (and shouldn't be).
> >
> > I think you pretty much need the recovery conflict handling infrastructure I
> > referenced upthread, which recognized during replay if a record has a conflict
> > with a slot on a standby.  And then ontop of that you can build something like
> > this patch.
> >
> 
> OK. Understood, thanks Andres.

I would love to see this feature in PG 15.  Can someone explain its
current status?  Thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: support for CREATE MODULE
Next
From: Thomas Munro
Date:
Subject: Re: WaitLatchOrSocket seems to not count to 4 right...