Re: Logical Replication slot disappeared after promote Standby

From: Perumal Raj <perucinci(at)gmail(dot)com>
To: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Logical Replication slot disappeared after promote Standby
Date: 2025-06-13 00:53:10
Message-ID: CALvqh4p3e7Z07=Sh2ZN0pQg9SgRCwmkT5qN7mWcdyFLrR9y0Ng@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Hou zj

I have found some strange issue , but not sure if I am doing anything wrong.

*I am able to see logical slot at STANDBY even after promote. 👏*

Importantly Logical replication slot is persistance in STANDBYs which
already established connection with Primary before logical replication slot
creation.

But If I create any new replica(Direct to Primary) after logical
replication slot creation, then its not persistance*(temporary=true) .*

*New Replica : *
node | slot_name | slot_type | temporary | active | plugin
| database | failover | synced | restart_lsn | confirmed_flush_lsn |
inactive_since
----------+--------------------+-----------+-----------+--------+----------+---------------+----------+--------+-------------+---------------------+------------------------------
stand-by | kafka_logical_slot | logical | t | t | pgoutput
| replica_test | t | t | 0/6C000000 | |
2025-06-13 00:43:15.61492+00

*Old Replica ,*
node | slot_name | slot_type | temporary | active | plugin
| database | failover | synced | restart_lsn | confirmed_flush_lsn |
inactive_since
----------+--------------------+-----------+-----------+--------+----------+---------------+----------+--------+-------------+---------------------+-------------------------------
stand-by | kafka_logical_slot | logical | f | f | pgoutput
| replica_test | t | t | 0/6D000060 | 0/6D000098 |
2025-06-13 00:45:11.547671+00

Not sure if any Pre-Req missing in my test environment. Or any limitation .

I have tested this feature with Kafka/Debezium version 3.1 , Not sure if
that creates different way

Please share some light here ,

Thanks for the time.

On Thu, Jun 12, 2025 at 8:09 AM Perumal Raj <perucinci(at)gmail(dot)com> wrote:

> Thanks Hou zj
>
> I will capture log message and share it with you,
>
> temporary column marked as 'false' every where , But synced column marked
> as 'false' in Primary whereas it was 'true' in both Direct STANDBYs
>
> #3 : No , I didn't drop slot at Primary. Infact Secondary B ( Another
> Direct Standby) still showing slot.
>
>
> On Thu, Jun 12, 2025 at 1:44 AM Zhijie Hou (Fujitsu) <
> houzj(dot)fnst(at)fujitsu(dot)com> wrote:
>
>> On Thu, Jun 12, 2025 at 4:08 PM Perumal Raj wrote:
>> > Hi Community,
>> >
>> > I have installed postgres version 17.5 with following setup,
>> >
>> > Primary
>> > -- Secondary A
>> > -- Secondary B
>> > -- Secondary C
>> >
>> > Config:
>> > wal_level = 'logical'
>> > max_wal_senders = '10'
>> > max_replication_slots = '10'
>> > wal_keep_size = '512MB'
>> > hot_standby = 'on'
>> > sync_replication_slots = 'on'
>> > hot_standby_feedback = 'on'
>> > synchronized_standby_slots = 'Kafka_logical_slot'
>> >
>> >
>> > 1. slotsync worker is running all the time ( Automatic sync)
>> > 2. When I create logical replication slot(Kafka_logical_slot) in
>> Primary, it
>> > got synced on both Secondary A and > Secondary B
>> > 3. It didn't appear in Secondary C , Since its not direct replica.
>> >
>> > Issue : When I stop Primary node and promote one of the Direct secondary
>> > (A,B) node. logical replication slot is vanished.
>> >
>> > Am I missing any configuration ?
>> >
>> > Please share your experience.
>>
>> Thanks for reporting.
>>
>> To narrow down potential causes, please confirm the following:
>>
>> 1) One possibility is that the slot has not been successfully
>> synchronized to
>> the standby. To verify, check for the presence of the following log
>> message:
>>
>> LOG: newly created replication slot "your_slot" is sync-ready now
>>
>> If this message is absent, it indicates that the slot has not been
>> successfully
>> synced. Additionally, you can confirm the sync status by inspecting the
>> pg_replication_slots.temporary field on the standby; a value of true
>> suggests
>> that the slot sync has not completed.
>>
>> 2) We typically recommend specifying the primary_slot_name on the standby
>> to
>> prevent slot invalidation due to catalog row removal on the primary.
>> Please
>> check your logs for possible invalidation messages:
>>
>> LOG: invalidating obsolete replication slot "your_slot"
>> or
>> LOG: terminating process 12344 to release replication slot "your_slot"
>>
>> 3) Is there a chance that the slot was dropped on the primary before
>> stopping
>> it and promoting the standby? If so, the synced slot would also be
>> dropped
>> in this scenario.
>>
>> Best Regards,
>> Hou zj
>>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Xuneng Zhou 2025-06-13 01:18:04 Re: Add progressive backoff to XactLockTableWait functions
Previous Message Fujii Masao 2025-06-13 00:39:54 Re: pg_dump --with-* options