Re: Restrict copying of invalidated replication slots

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Restrict copying of invalidated replication slots
Date: 2025-02-27 05:16:22
Message-ID: CAD21AoA+m7vMo+DqXv9yUwpiLFQEMQ-UEp6w58-bLWePg4E8Nw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 25, 2025 at 7:33 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Tue, Feb 25, 2025 at 11:21 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > On Tue, Feb 25, 2025 at 2:36 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > > >
> > > > Scenario-3: the source gets invalidated after creating the copied slot
> > > > (i.e. after create_logical/physical_replication_slot()). In this case,
> > > > since the newly copied slot have the same restart_lsn as the source
> > > > slot, both slots are invalidated.
> > > >
> > >
> > > Which part of the code will cover Scenario-3? Shouldn't we give ERROR
> > > for Scenario-3 as well?
> >
> > In scenario-3, the backend process executing
> > pg_copy_logical/physical_replication_slot() already holds the new
> > copied slot and its restart_lsn is the same or older than the source
> > slot's restart_lsn. Therefore, if the source slot is invalidated at
> > that timing, the copied slot is invalidated too, resulting in an error
> > by the backend.
> >
>
> AFAICU, InvalidateObsoleteReplicationSlots() is not serialized with
> this operation. So, isn't it possible that the source slot exists at
> the later position in ReplicationSlotCtl->replication_slots and the
> loop traversing slots is already ahead from the point where the newly
> copied slot is created?

Good point. I think it's possible.

> If so, the newly created slot won't be marked
> as invalid whereas the source slot will be marked as invalid. I agree
> that even in such a case, at a later point, the newly created slot
> will also be marked as invalid.

The wal_status of the newly created slot would immediately become
'lost' and the next checkpoint will invalidate it. Do we need to do
something to deal with this case?

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-02-27 05:16:55 Re: new commitfest transition guidance
Previous Message Michael Paquier 2025-02-27 05:08:04 Re: Fix api misuse (src/bin/pg_amcheck/pg_amcheck.c)