On Fri, Jan 12, 2024 at 12:07 PM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
>
> On Fri, Jan 12, 2024 at 08:42:39AM +0530, Amit Kapila wrote:
> > On Thu, Jan 11, 2024 at 9:11 PM Bertrand Drouvot
> > <bertranddrouvot.pg@gmail.com> wrote:
> > >
> > > I'm not sure to follow here. If the remote slot is re-created then it would
> > > be also dropped / re-created locally, or am I missing something?
> > >
> >
> > As our slot-syncing mechanism is asynchronous (from time to time we
> > check the slot information on primary), isn't it possible that the
> > same name slot is dropped and recreated between slot-sync worker's
> > checks?
> >
>
> Yeah, I should have thought harder ;-) So for this case, let's imagine that If we
> had an easy way to detect that a remote slot has been drop/re-created then I think
> we would also drop and re-create it on the standby too.
>
> If so, I think we should then update all the fields (that we're currently updating
> in the "create locally" case) when we detect that (at least) one of the following differs:
>
> - dboid
> - plugin
> - two_phase
>
Right, I think even if any of restart/confirmed LSN's or xmin has
changed then also there is no harm in simply copying all the fields
from remote_slot as done by Hou-San in latest patch.
> Maybe the "best" approach would be to have a way to detect that a slot has been
> re-created on the primary (but that would mean rely on more than the slot name
> to "identify" a slot and probably add a new member to the struct to do so).
>
Right, I also thought so but not sure further complicating the slot
machinery is worth detecting this case explicitly. If we see any
problem with the idea discussed then we may need to think something
along those lines.
--
With Regards,
Amit Kapila.