Re: START_REPLICATION SLOT causing a crash in an assert build - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: START_REPLICATION SLOT causing a crash in an assert build
Date
Msg-id CAD21AoA-eC2A9xQRaCuW9fA6N0xvw7gZwJKCqc+XMdRvWcGHgg@mail.gmail.com
Whole thread Raw
In response to Re: START_REPLICATION SLOT causing a crash in an assert build  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Fri, Oct 7, 2022 at 8:00 AM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2022-10-06 14:10:46 +0900, Kyotaro Horiguchi wrote:
> > +1. FWIW, the atttached is an example of what it looks like if we
> > avoid file format change.
>
> What about if we go the other direction - simply remove the name from the
> stats entry at all. I don't actually think we need it anymore. Unless I am
> missing something right now - entirely possible! - the danger that
> pgstat_acquire_replslot() mentions doesn't actually exist [anymore]. After a
> crash we throw away the old stats data and if a slot is dropped while shut
> down, we'll not load the slot data at startup.

+1. I think it works. Since the replication slot index doesn't change
during server running we can fetch the name from
ReplicationSlotCtl->replication_slots.

If we don't need the name in stats entry, pgstat_acquire_replslot() is
no longer necessary?

Regards,

-- 
Masahiko Sawada
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Perform streaming logical transactions by background workers and parallel apply
Next
From: Masahiko Sawada
Date:
Subject: Re: Perform streaming logical transactions by background workers and parallel apply