From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> |
Cc: | pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Mention idle_replication_slot_timeout in pg_replication_slots docs |
Date: | 2025-07-03 14:13:05 |
Message-ID: | 2016d3c0-0106-400c-91a1-80a21518fded@oss.nttdata.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On 2025/07/02 16:12, Fujii Masao wrote:
>
>
> On 2025/07/01 13:52, Nisha Moond wrote:
>> On Mon, Jun 30, 2025 at 6:12 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
>>> Is this true starting from v16, when logical replication from standby was introduced?
>>> In other words, in v15 and earlier, only max_slot_wal_keep_size could cause
>>> the wal_status to become "unreserved" or "lost"? I'm wondering where to back-patch
>>> this fix to.
>>>
>>
>> I also think we should back-patch this till v16, since that’s when
>> additional slot invalidation causes were also introduced(commit
>> be87200). And since then “max_slot_wal_keep_size” is no longer the
>> sole reason for “unreserved” or “lost” status.
>
> Okay, I've prepared two patches:
>
> - 0001 removes the incorrect line: "If restart_lsn is NULL, this field is null."
> This should be back-patched to v13.
> - 0002 updates the description of the wal_status to reflect that max_slot_wal_keep_size
> is not the only cause of the lost state. This should be back-patched to v16.
>
> Barrng objections, I will commit these patches.
I've pushed the patches. Thanks!
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
From | Date | Subject | |
---|---|---|---|
Next Message | PG Doc comments form | 2025-07-04 20:51:17 | 2.4 Tutorial COPY weather.txt -- From where? |
Previous Message | Fujii Masao | 2025-07-02 16:30:13 | Minor Improvements to pg_buffercache documentation |