Re: START_REPLICATION SLOT causing a crash in an assert build

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, michael(at)paquier(dot)xyz, jkatz(at)postgresql(dot)org, jcasanov(at)systemguards(dot)com(dot)ec, pgsql-hackers(at)postgresql(dot)org, john(dot)naylor(at)enterprisedb(dot)com
Subject: Re: START_REPLICATION SLOT causing a crash in an assert build
Date: 2022-10-07 03:14:40
Message-ID: CAD21AoA-eC2A9xQRaCuW9fA6N0xvw7gZwJKCqc+XMdRvWcGHgg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 7, 2022 at 8:00 AM Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2022-10-07 03:17:22 Re: Perform streaming logical transactions by background workers and parallel apply
Previous Message Peter Smith 2022-10-07 03:08:07 Re: Perform streaming logical transactions by background workers and parallel apply