On Wed, Jun 28, 2023 at 12:19 PM Drouvot, Bertrand <bertranddrouvot...@gmail.com> wrote: > > On 6/26/23 12:34 PM, Amit Kapila wrote: > > On Mon, Jun 26, 2023 at 11:15 AM Drouvot, Bertrand > > <bertranddrouvot...@gmail.com> wrote: > >> > >> On 6/20/23 12:22 PM, Amit Kapila wrote: > >>> On Mon, Jun 19, 2023 at 9:56 PM Drouvot, Bertrand > >>> <bertranddrouvot...@gmail.com> wrote: > >> > >>>> In such a case (slot valid on the primary but invalidated on the > >>>> standby) then I think we > >>>> could drop and recreate the invalidated slot on the standby. > >>>> > >>> > >>> Will it be safe? Because after recreating the slot, it will reserve > >>> the new WAL location and build the snapshot based on that which might > >>> miss some important information in the snapshot. For example, to > >>> update the slot's position with new information from the primary, the > >>> patch uses pg_logical_replication_slot_advance() which means it will > >>> process all records and update the snapshot via > >>> DecodeCommit->SnapBuildCommitTxn(). > >> > >> Your concern is that the slot could have been consumed on the standby? > >> > >> I mean, if we suppose the "synchronized" slot can't be consumed on the > >> standby then > >> drop/recreate such an invalidated slot would be ok? > >> > > > > That also may not be sufficient because as soon as the slot is > > invalidated/dropped, the required WAL could be removed on standby. > > > > Yeah, I think once the slot is dropped we just have to wait for the slot to > be re-created on the standby according to the new synchronize_slot_names GUC. > > Assuming the initial slot "creation" on the standby (coming from the > synchronize_slot_names usage) > is working "correctly" then it should also work "correctly" once the slot is > dropped. >
I also think so. > If we agree that a synchronized slot can not/should not be consumed (will > implement this behavior) then > I think the proposed scenario above should make sense, do you agree? > Yeah, I also can't think of a use case for this. So, we can probably disallow it and document the same. I guess if we came across a use case for this, we can rethink allowing to consume the changes from synchronized slots. -- With Regards, Amit Kapila.