agora inbox for pgsql-docs@postgresql.org
help / color / mirror / Atom feedMention idle_replication_slot_timeout in pg_replication_slots docs
13+ messages / 3 participants
[nested] [flat]
* Mention idle_replication_slot_timeout in pg_replication_slots docs
@ 2025-06-25 16:25 Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 2 replies; 13+ messages in thread
From: Fujii Masao @ 2025-06-25 16:25 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org
Hi,
The pg_replication_slots documentation mentions only max_slot_wal_keep_size
as a condition under which the wal_status column can show unreserved or lost.
However, since commit ac0e33136ab, idle_replication_slot_timeout can also
cause this behavior when it is set. This has not been documented yet.
https://www.postgresql.org/docs/devel/view-pg-replication-slots.html
So, how about updating the documentation to also mention
idle_replication_slot_timeout as a factor that can cause wal_status to
become unreserved or lost? Patch attached.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
From 7bccb16c1119e00194939dfe154d1aa0e8d19842 Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Thu, 26 Jun 2025 00:55:46 +0900
Subject: [PATCH v1] doc: Mention idle_replication_slot_timeout in
pg_replication_slots docs.
The pg_replication_slots documentation previously mentioned only
max_slot_wal_keep_size as a condition under which the wal_status column
can show unreserved or lost. However, since commit ac0e33136ab,
idle_replication_slot_timeout can also cause this behavior when it is set.
This was not documented.
This commit updates the documentation to also mention
idle_replication_slot_timeout as a factor that can cause wal_status
to become unreserved or lost.
---
doc/src/sgml/system-views.sgml | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml
index 986ae1f543d..f97da9f7e61 100644
--- a/doc/src/sgml/system-views.sgml
+++ b/doc/src/sgml/system-views.sgml
@@ -2832,8 +2832,9 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
</itemizedlist>
The last two states are seen only when
<xref linkend="guc-max-slot-wal-keep-size"/> is
- non-negative. If <structfield>restart_lsn</structfield> is NULL, this
- field is null.
+ non-negative and/or <xref linkend="guc-idle-replication-slot-timeout"/>
+ is greater than zero. If <structfield>restart_lsn</structfield> is NULL,
+ this field is null.
</para></entry>
</row>
--
2.49.0
Attachments:
[text/plain] v1-0001-doc-Mention-idle_replication_slot_timeout-in-pg_r.patch (1.5K, ../../78b34e84-2195-4f28-a151-5d204a382fdd@oss.nttdata.com/2-v1-0001-doc-Mention-idle_replication_slot_timeout-in-pg_r.patch)
download | inline diff:
From 7bccb16c1119e00194939dfe154d1aa0e8d19842 Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Thu, 26 Jun 2025 00:55:46 +0900
Subject: [PATCH v1] doc: Mention idle_replication_slot_timeout in
pg_replication_slots docs.
The pg_replication_slots documentation previously mentioned only
max_slot_wal_keep_size as a condition under which the wal_status column
can show unreserved or lost. However, since commit ac0e33136ab,
idle_replication_slot_timeout can also cause this behavior when it is set.
This was not documented.
This commit updates the documentation to also mention
idle_replication_slot_timeout as a factor that can cause wal_status
to become unreserved or lost.
---
doc/src/sgml/system-views.sgml | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml
index 986ae1f543d..f97da9f7e61 100644
--- a/doc/src/sgml/system-views.sgml
+++ b/doc/src/sgml/system-views.sgml
@@ -2832,8 +2832,9 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
</itemizedlist>
The last two states are seen only when
<xref linkend="guc-max-slot-wal-keep-size"/> is
- non-negative. If <structfield>restart_lsn</structfield> is NULL, this
- field is null.
+ non-negative and/or <xref linkend="guc-idle-replication-slot-timeout"/>
+ is greater than zero. If <structfield>restart_lsn</structfield> is NULL,
+ this field is null.
</para></entry>
</row>
--
2.49.0
^ permalink raw reply [nested|flat] 13+ messages in thread
* RE: Mention idle_replication_slot_timeout in pg_replication_slots docs
@ 2025-06-26 06:43 Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
1 sibling, 1 reply; 13+ messages in thread
From: Hayato Kuroda (Fujitsu) @ 2025-06-26 06:43 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; +Cc: pgsql-docs@lists.postgresql.org <pgsql-docs@lists.postgresql.org>
Dear Fujii-san,
> The pg_replication_slots documentation mentions only max_slot_wal_keep_size
> as a condition under which the wal_status column can show unreserved or lost.
> However, since commit ac0e33136ab, idle_replication_slot_timeout can also
> cause this behavior when it is set. This has not been documented yet.
> https://www.postgresql.org/docs/devel/view-pg-replication-slots.html
Oh, I feel the doc should be also updated.
> So, how about updating the documentation to also mention
> idle_replication_slot_timeout as a factor that can cause wal_status to
> become unreserved or lost? Patch attached.
One comment:
```
<para>
<literal>lost</literal> means that some required WAL files have
been removed and this slot is no longer usable.
</para>
```
IIUC, there is a case that status is "lost" but the required WALs have not been
dropped yet if the slot was invalidated due to the timeout. How about removing the
first part:
```
<literal>lost</literal> means that this slot is no longer usable.
```
Best regards,
Hayato Kuroda
FUJITSU LIMITED
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Mention idle_replication_slot_timeout in pg_replication_slots docs
@ 2025-06-26 06:46 Nisha Moond <nisha.moond412@gmail.com>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
1 sibling, 1 reply; 13+ messages in thread
From: Nisha Moond @ 2025-06-26 06:46 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; +Cc: pgsql-docs@lists.postgresql.org
On Wed, Jun 25, 2025 at 9:56 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>
> Hi,
>
> The pg_replication_slots documentation mentions only max_slot_wal_keep_size
> as a condition under which the wal_status column can show unreserved or lost.
> However, since commit ac0e33136ab, idle_replication_slot_timeout can also
> cause this behavior when it is set. This has not been documented yet.
> https://www.postgresql.org/docs/devel/view-pg-replication-slots.html
>
+1 to the doc update.
> So, how about updating the documentation to also mention
> idle_replication_slot_timeout as a factor that can cause wal_status to
> become unreserved or lost? Patch attached.
>
Since idle_replication_slot_timeout can only cause wal_status to
become 'lost' and not 'unreserved', perhaps we can reword the sentence
slightly for clarity, suggestion -
"The last two states are seen when max_slot_wal_keep_size is
non-negative and, the 'lost' state may also appear when
idle_replication_slot_timeout is greater than zero."
Please feel free to rephrase if needed.
--
Thanks,
Nisha
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Mention idle_replication_slot_timeout in pg_replication_slots docs
@ 2025-06-26 07:55 Fujii Masao <masao.fujii@oss.nttdata.com>
parent: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
0 siblings, 1 reply; 13+ messages in thread
From: Fujii Masao @ 2025-06-26 07:55 UTC (permalink / raw)
To: Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>; +Cc: pgsql-docs@lists.postgresql.org <pgsql-docs@lists.postgresql.org>
On 2025/06/26 15:43, Hayato Kuroda (Fujitsu) wrote:
> Dear Fujii-san,
>
>> The pg_replication_slots documentation mentions only max_slot_wal_keep_size
>> as a condition under which the wal_status column can show unreserved or lost.
>> However, since commit ac0e33136ab, idle_replication_slot_timeout can also
>> cause this behavior when it is set. This has not been documented yet.
>> https://www.postgresql.org/docs/devel/view-pg-replication-slots.html
>
> Oh, I feel the doc should be also updated.
Thanks for the review!
>> So, how about updating the documentation to also mention
>> idle_replication_slot_timeout as a factor that can cause wal_status to
>> become unreserved or lost? Patch attached.
>
> One comment:
>
> ```
> <para>
> <literal>lost</literal> means that some required WAL files have
> been removed and this slot is no longer usable.
> </para>
> ```
>
> IIUC, there is a case that status is "lost" but the required WALs have not been
> dropped yet if the slot was invalidated due to the timeout. How about removing the
> first part:
>
> ```
> <literal>lost</literal> means that this slot is no longer usable.
> ```
Agreed. Attached is the updated version of the patch.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
From a730908764b2255fd7ab36441417bddc643d4a5e Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Thu, 26 Jun 2025 16:49:59 +0900
Subject: [PATCH v2] doc: Mention idle_replication_slot_timeout in
pg_replication_slots docs.
The pg_replication_slots documentation previously mentioned only
max_slot_wal_keep_size as a condition under which the wal_status column
can show unreserved or lost. However, since commit ac0e33136ab,
idle_replication_slot_timeout can also cause this behavior when it is set.
This was not documented.
This commit updates the documentation to also mention
idle_replication_slot_timeout as a factor that can cause wal_status
to become unreserved or lost.
Author: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>
Reviewed-by: Nisha Moond <nisha.moond412@gmail.com>
Discussion: https://postgr.es/m/78b34e84-2195-4f28-a151-5d204a382fdd@oss.nttdata.com
---
doc/src/sgml/system-views.sgml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml
index 986ae1f543d..308e5dabf3b 100644
--- a/doc/src/sgml/system-views.sgml
+++ b/doc/src/sgml/system-views.sgml
@@ -2825,15 +2825,15 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
</listitem>
<listitem>
<para>
- <literal>lost</literal> means that some required WAL files have
- been removed and this slot is no longer usable.
+ <literal>lost</literal> means that this slot is no longer usable.
</para>
</listitem>
</itemizedlist>
The last two states are seen only when
<xref linkend="guc-max-slot-wal-keep-size"/> is
- non-negative. If <structfield>restart_lsn</structfield> is NULL, this
- field is null.
+ non-negative and/or <xref linkend="guc-idle-replication-slot-timeout"/>
+ is greater than zero. If <structfield>restart_lsn</structfield> is NULL,
+ this field is null.
</para></entry>
</row>
--
2.49.0
Attachments:
[text/plain] v2-0001-doc-Mention-idle_replication_slot_timeout-in-pg_r.patch (2.0K, ../../8b5ca8aa-dbc0-4f58-87bf-403352f3d00c@oss.nttdata.com/2-v2-0001-doc-Mention-idle_replication_slot_timeout-in-pg_r.patch)
download | inline diff:
From a730908764b2255fd7ab36441417bddc643d4a5e Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Thu, 26 Jun 2025 16:49:59 +0900
Subject: [PATCH v2] doc: Mention idle_replication_slot_timeout in
pg_replication_slots docs.
The pg_replication_slots documentation previously mentioned only
max_slot_wal_keep_size as a condition under which the wal_status column
can show unreserved or lost. However, since commit ac0e33136ab,
idle_replication_slot_timeout can also cause this behavior when it is set.
This was not documented.
This commit updates the documentation to also mention
idle_replication_slot_timeout as a factor that can cause wal_status
to become unreserved or lost.
Author: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>
Reviewed-by: Nisha Moond <nisha.moond412@gmail.com>
Discussion: https://postgr.es/m/78b34e84-2195-4f28-a151-5d204a382fdd@oss.nttdata.com
---
doc/src/sgml/system-views.sgml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml
index 986ae1f543d..308e5dabf3b 100644
--- a/doc/src/sgml/system-views.sgml
+++ b/doc/src/sgml/system-views.sgml
@@ -2825,15 +2825,15 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
</listitem>
<listitem>
<para>
- <literal>lost</literal> means that some required WAL files have
- been removed and this slot is no longer usable.
+ <literal>lost</literal> means that this slot is no longer usable.
</para>
</listitem>
</itemizedlist>
The last two states are seen only when
<xref linkend="guc-max-slot-wal-keep-size"/> is
- non-negative. If <structfield>restart_lsn</structfield> is NULL, this
- field is null.
+ non-negative and/or <xref linkend="guc-idle-replication-slot-timeout"/>
+ is greater than zero. If <structfield>restart_lsn</structfield> is NULL,
+ this field is null.
</para></entry>
</row>
--
2.49.0
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Mention idle_replication_slot_timeout in pg_replication_slots docs
@ 2025-06-26 08:03 Fujii Masao <masao.fujii@oss.nttdata.com>
parent: Nisha Moond <nisha.moond412@gmail.com>
0 siblings, 1 reply; 13+ messages in thread
From: Fujii Masao @ 2025-06-26 08:03 UTC (permalink / raw)
To: Nisha Moond <nisha.moond412@gmail.com>; +Cc: pgsql-docs@lists.postgresql.org
On 2025/06/26 15:46, Nisha Moond wrote:
> On Wed, Jun 25, 2025 at 9:56 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>>
>> Hi,
>>
>> The pg_replication_slots documentation mentions only max_slot_wal_keep_size
>> as a condition under which the wal_status column can show unreserved or lost.
>> However, since commit ac0e33136ab, idle_replication_slot_timeout can also
>> cause this behavior when it is set. This has not been documented yet.
>> https://www.postgresql.org/docs/devel/view-pg-replication-slots.html
>>
>
> +1 to the doc update.
Thanks for the review!
>> So, how about updating the documentation to also mention
>> idle_replication_slot_timeout as a factor that can cause wal_status to
>> become unreserved or lost? Patch attached.
>>
>
> Since idle_replication_slot_timeout can only cause wal_status to
> become 'lost' and not 'unreserved', perhaps we can reword the sentence
> slightly for clarity, suggestion -
> "The last two states are seen when max_slot_wal_keep_size is
> non-negative and, the 'lost' state may also appear when
> idle_replication_slot_timeout is greater than zero."
I was thinking that when idle_replication_slot_timeout triggers,
the following functions are called, and that wal_status can become
"unreserved" before ReplicationSlotRelease() runs. It's very short
period, though. Am I wrong?
ReplicationSlotMarkDirty();
ReplicationSlotSave();
ReplicationSlotRelease();
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
^ permalink raw reply [nested|flat] 13+ messages in thread
* RE: Mention idle_replication_slot_timeout in pg_replication_slots docs
@ 2025-06-27 05:03 Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 0 replies; 13+ messages in thread
From: Hayato Kuroda (Fujitsu) @ 2025-06-27 05:03 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; +Cc: pgsql-docs@lists.postgresql.org <pgsql-docs@lists.postgresql.org>
Dear Fujii-san,
> Agreed. Attached is the updated version of the patch.
I confirmed that my point was fixed. LGTM.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Mention idle_replication_slot_timeout in pg_replication_slots docs
@ 2025-06-27 06:32 Nisha Moond <nisha.moond412@gmail.com>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 1 reply; 13+ messages in thread
From: Nisha Moond @ 2025-06-27 06:32 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; +Cc: pgsql-docs@lists.postgresql.org
On Thu, Jun 26, 2025 at 1:33 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>
>
>
> On 2025/06/26 15:46, Nisha Moond wrote:
> > On Wed, Jun 25, 2025 at 9:56 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> >>
> >> Hi,
> >>
> >> The pg_replication_slots documentation mentions only max_slot_wal_keep_size
> >> as a condition under which the wal_status column can show unreserved or lost.
> >> However, since commit ac0e33136ab, idle_replication_slot_timeout can also
> >> cause this behavior when it is set. This has not been documented yet.
> >> https://www.postgresql.org/docs/devel/view-pg-replication-slots.html
> >>
> >
> > +1 to the doc update.
>
> Thanks for the review!
>
>
> >> So, how about updating the documentation to also mention
> >> idle_replication_slot_timeout as a factor that can cause wal_status to
> >> become unreserved or lost? Patch attached.
> >>
> >
> > Since idle_replication_slot_timeout can only cause wal_status to
> > become 'lost' and not 'unreserved', perhaps we can reword the sentence
> > slightly for clarity, suggestion -
> > "The last two states are seen when max_slot_wal_keep_size is
> > non-negative and, the 'lost' state may also appear when
> > idle_replication_slot_timeout is greater than zero."
>
> I was thinking that when idle_replication_slot_timeout triggers,
> the following functions are called, and that wal_status can become
> "unreserved" before ReplicationSlotRelease() runs. It's very short
> period, though. Am I wrong?
>
> ReplicationSlotMarkDirty();
> ReplicationSlotSave();
> ReplicationSlotRelease();
>
Thank you for pointing it out.
You are correct that while the checkpointer is in the process of
invalidating a slot, it sets its PID as the slot’s active_pid. During
this short window, if a user queries pg_replication_slot, the
underlying function pg_get_replication_slots will compute the
wal_status as 'unreserved' for the invalidated slot because the slot
has a valid active_pid.
That said, it's reasonable to mention in the doc that 'unreserved' may
appear when idle_replication_slot_timeout is greater than zero, as
this can indeed happen. So, let's retain the current description.
However, this behavior isn’t specific to
idle_replication_slot_timeout. For example, when a slot is being
invalidated due to a different cause "wal_level_insufficient",
'unreserved' may also briefly appear in wal_status.
The current patch LGTM.
--
Thanks,
Nisha
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Mention idle_replication_slot_timeout in pg_replication_slots docs
@ 2025-06-27 12:10 Fujii Masao <masao.fujii@oss.nttdata.com>
parent: Nisha Moond <nisha.moond412@gmail.com>
0 siblings, 1 reply; 13+ messages in thread
From: Fujii Masao @ 2025-06-27 12:10 UTC (permalink / raw)
To: Nisha Moond <nisha.moond412@gmail.com>; +Cc: pgsql-docs@lists.postgresql.org
On 2025/06/27 15:32, Nisha Moond wrote:
> On Thu, Jun 26, 2025 at 1:33 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>>
>>
>>
>> On 2025/06/26 15:46, Nisha Moond wrote:
>>> On Wed, Jun 25, 2025 at 9:56 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> The pg_replication_slots documentation mentions only max_slot_wal_keep_size
>>>> as a condition under which the wal_status column can show unreserved or lost.
>>>> However, since commit ac0e33136ab, idle_replication_slot_timeout can also
>>>> cause this behavior when it is set. This has not been documented yet.
>>>> https://www.postgresql.org/docs/devel/view-pg-replication-slots.html
>>>>
>>>
>>> +1 to the doc update.
>>
>> Thanks for the review!
>>
>>
>>>> So, how about updating the documentation to also mention
>>>> idle_replication_slot_timeout as a factor that can cause wal_status to
>>>> become unreserved or lost? Patch attached.
>>>>
>>>
>>> Since idle_replication_slot_timeout can only cause wal_status to
>>> become 'lost' and not 'unreserved', perhaps we can reword the sentence
>>> slightly for clarity, suggestion -
>>> "The last two states are seen when max_slot_wal_keep_size is
>>> non-negative and, the 'lost' state may also appear when
>>> idle_replication_slot_timeout is greater than zero."
>>
>> I was thinking that when idle_replication_slot_timeout triggers,
>> the following functions are called, and that wal_status can become
>> "unreserved" before ReplicationSlotRelease() runs. It's very short
>> period, though. Am I wrong?
>>
>> ReplicationSlotMarkDirty();
>> ReplicationSlotSave();
>> ReplicationSlotRelease();
>>
>
> Thank you for pointing it out.
> You are correct that while the checkpointer is in the process of
> invalidating a slot, it sets its PID as the slot’s active_pid. During
> this short window, if a user queries pg_replication_slot, the
> underlying function pg_get_replication_slots will compute the
> wal_status as 'unreserved' for the invalidated slot because the slot
> has a valid active_pid.
>
> That said, it's reasonable to mention in the doc that 'unreserved' may
> appear when idle_replication_slot_timeout is greater than zero, as
> this can indeed happen. So, let's retain the current description.
>
> However, this behavior isn’t specific to
> idle_replication_slot_timeout. For example, when a slot is being
> invalidated due to a different cause "wal_level_insufficient",
> 'unreserved' may also briefly appear in wal_status.
Yes, and "lost" can appear for various reasons, including wal_level_insufficient,
so it seems odd to highlight max_slot_wal_keep_size as the cause of the "lost"
status in the note. It would probably be better to remove the mention of "lost"
from that note.
As for "unreserved", it can also occur for different reasons, but typically,
it happens when max_slot_wal_keep_size is set to a non-negative value.
So it might make sense to keep the explanation focused just on "unreserved"
and max_slot_wal_keep_size. For example:
----------------------
<listitem>
<para>
<literal>unreserved</literal> means that the slot no longer
retains the required WAL files and some of them are to be removed at
- the next checkpoint. This state can return
+ the next checkpoint. This can occur when
+ <xref linkend="guc-max-slot-wal-keep-size"/> is set to
+ a non-negative value. This state can return
to <literal>reserved</literal> or <literal>extended</literal>.
</para>
</listitem>
<listitem>
----------------------
What do you think?
Also, I noticed the note that says “If <structfield>restart_lsn</structfield>
is NULL, this field is null” seems inaccurate. For example, when "wal_removed"
happens, restart_lsn is NULL but wal_status is "lost". So maybe we should remove
that note as well?
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Mention idle_replication_slot_timeout in pg_replication_slots docs
@ 2025-06-30 11:32 Nisha Moond <nisha.moond412@gmail.com>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 1 reply; 13+ messages in thread
From: Nisha Moond @ 2025-06-30 11:32 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; +Cc: pgsql-docs@lists.postgresql.org
On Fri, Jun 27, 2025 at 5:40 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>
>
>
> On 2025/06/27 15:32, Nisha Moond wrote:
> > On Thu, Jun 26, 2025 at 1:33 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> >>
> >>
> >>
> >> On 2025/06/26 15:46, Nisha Moond wrote:
> >>> On Wed, Jun 25, 2025 at 9:56 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> The pg_replication_slots documentation mentions only max_slot_wal_keep_size
> >>>> as a condition under which the wal_status column can show unreserved or lost.
> >>>> However, since commit ac0e33136ab, idle_replication_slot_timeout can also
> >>>> cause this behavior when it is set. This has not been documented yet.
> >>>> https://www.postgresql.org/docs/devel/view-pg-replication-slots.html
> >>>>
> >>>
> >>> +1 to the doc update.
> >>
> >> Thanks for the review!
> >>
> >>
> >>>> So, how about updating the documentation to also mention
> >>>> idle_replication_slot_timeout as a factor that can cause wal_status to
> >>>> become unreserved or lost? Patch attached.
> >>>>
> >>>
> >>> Since idle_replication_slot_timeout can only cause wal_status to
> >>> become 'lost' and not 'unreserved', perhaps we can reword the sentence
> >>> slightly for clarity, suggestion -
> >>> "The last two states are seen when max_slot_wal_keep_size is
> >>> non-negative and, the 'lost' state may also appear when
> >>> idle_replication_slot_timeout is greater than zero."
> >>
> >> I was thinking that when idle_replication_slot_timeout triggers,
> >> the following functions are called, and that wal_status can become
> >> "unreserved" before ReplicationSlotRelease() runs. It's very short
> >> period, though. Am I wrong?
> >>
> >> ReplicationSlotMarkDirty();
> >> ReplicationSlotSave();
> >> ReplicationSlotRelease();
> >>
> >
> > Thank you for pointing it out.
> > You are correct that while the checkpointer is in the process of
> > invalidating a slot, it sets its PID as the slot’s active_pid. During
> > this short window, if a user queries pg_replication_slot, the
> > underlying function pg_get_replication_slots will compute the
> > wal_status as 'unreserved' for the invalidated slot because the slot
> > has a valid active_pid.
> >
> > That said, it's reasonable to mention in the doc that 'unreserved' may
> > appear when idle_replication_slot_timeout is greater than zero, as
> > this can indeed happen. So, let's retain the current description.
> >
> > However, this behavior isn’t specific to
> > idle_replication_slot_timeout. For example, when a slot is being
> > invalidated due to a different cause "wal_level_insufficient",
> > 'unreserved' may also briefly appear in wal_status.
>
> Yes, and "lost" can appear for various reasons, including wal_level_insufficient,
> so it seems odd to highlight max_slot_wal_keep_size as the cause of the "lost"
> status in the note. It would probably be better to remove the mention of "lost"
> from that note.
>
+1
> As for "unreserved", it can also occur for different reasons, but typically,
> it happens when max_slot_wal_keep_size is set to a non-negative value.
> So it might make sense to keep the explanation focused just on "unreserved"
> and max_slot_wal_keep_size. For example:
>
> ----------------------
> <listitem>
> <para>
> <literal>unreserved</literal> means that the slot no longer
> retains the required WAL files and some of them are to be removed at
> - the next checkpoint. This state can return
> + the next checkpoint. This can occur when
> + <xref linkend="guc-max-slot-wal-keep-size"/> is set to
> + a non-negative value. This state can return
> to <literal>reserved</literal> or <literal>extended</literal>.
> </para>
> </listitem>
> <listitem>
> ----------------------
>
> What do you think?
>
The change LGTM, only a minor suggestion to add "typically", as “This
can typically occur when…” to indicate that max_slot_wal_keep_size is
one possible reason, not the only one.
>
> Also, I noticed the note that says “If <structfield>restart_lsn</structfield>
> is NULL, this field is null” seems inaccurate. For example, when "wal_removed"
> happens, restart_lsn is NULL but wal_status is "lost". So maybe we should remove
> that note as well?
You're right, the statement is not accurate.
We could rephrase it as: "If <structfield>restart_lsn</structfield> is
NULL, this field is either null or lost." But since 'unreserved' can
also appear briefly during invalidation, it might be better to remove
it altogether.
--
Thanks,
Nisha
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Mention idle_replication_slot_timeout in pg_replication_slots docs
@ 2025-06-30 12:42 Fujii Masao <masao.fujii@oss.nttdata.com>
parent: Nisha Moond <nisha.moond412@gmail.com>
0 siblings, 1 reply; 13+ messages in thread
From: Fujii Masao @ 2025-06-30 12:42 UTC (permalink / raw)
To: Nisha Moond <nisha.moond412@gmail.com>; +Cc: pgsql-docs@lists.postgresql.org
On 2025/06/30 20:32, Nisha Moond wrote:
> On Fri, Jun 27, 2025 at 5:40 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>>
>>
>>
>> On 2025/06/27 15:32, Nisha Moond wrote:
>>> On Thu, Jun 26, 2025 at 1:33 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>>>>
>>>>
>>>>
>>>> On 2025/06/26 15:46, Nisha Moond wrote:
>>>>> On Wed, Jun 25, 2025 at 9:56 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The pg_replication_slots documentation mentions only max_slot_wal_keep_size
>>>>>> as a condition under which the wal_status column can show unreserved or lost.
>>>>>> However, since commit ac0e33136ab, idle_replication_slot_timeout can also
>>>>>> cause this behavior when it is set. This has not been documented yet.
>>>>>> https://www.postgresql.org/docs/devel/view-pg-replication-slots.html
>>>>>>
>>>>>
>>>>> +1 to the doc update.
>>>>
>>>> Thanks for the review!
>>>>
>>>>
>>>>>> So, how about updating the documentation to also mention
>>>>>> idle_replication_slot_timeout as a factor that can cause wal_status to
>>>>>> become unreserved or lost? Patch attached.
>>>>>>
>>>>>
>>>>> Since idle_replication_slot_timeout can only cause wal_status to
>>>>> become 'lost' and not 'unreserved', perhaps we can reword the sentence
>>>>> slightly for clarity, suggestion -
>>>>> "The last two states are seen when max_slot_wal_keep_size is
>>>>> non-negative and, the 'lost' state may also appear when
>>>>> idle_replication_slot_timeout is greater than zero."
>>>>
>>>> I was thinking that when idle_replication_slot_timeout triggers,
>>>> the following functions are called, and that wal_status can become
>>>> "unreserved" before ReplicationSlotRelease() runs. It's very short
>>>> period, though. Am I wrong?
>>>>
>>>> ReplicationSlotMarkDirty();
>>>> ReplicationSlotSave();
>>>> ReplicationSlotRelease();
>>>>
>>>
>>> Thank you for pointing it out.
>>> You are correct that while the checkpointer is in the process of
>>> invalidating a slot, it sets its PID as the slot’s active_pid. During
>>> this short window, if a user queries pg_replication_slot, the
>>> underlying function pg_get_replication_slots will compute the
>>> wal_status as 'unreserved' for the invalidated slot because the slot
>>> has a valid active_pid.
>>>
>>> That said, it's reasonable to mention in the doc that 'unreserved' may
>>> appear when idle_replication_slot_timeout is greater than zero, as
>>> this can indeed happen. So, let's retain the current description.
>>>
>>> However, this behavior isn’t specific to
>>> idle_replication_slot_timeout. For example, when a slot is being
>>> invalidated due to a different cause "wal_level_insufficient",
>>> 'unreserved' may also briefly appear in wal_status.
>>
>> Yes, and "lost" can appear for various reasons, including wal_level_insufficient,
>> so it seems odd to highlight max_slot_wal_keep_size as the cause of the "lost"
>> status in the note. It would probably be better to remove the mention of "lost"
>> from that note.
>>
>
> +1
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.
>> As for "unreserved", it can also occur for different reasons, but typically,
>> it happens when max_slot_wal_keep_size is set to a non-negative value.
>> So it might make sense to keep the explanation focused just on "unreserved"
>> and max_slot_wal_keep_size. For example:
>>
>> ----------------------
>> <listitem>
>> <para>
>> <literal>unreserved</literal> means that the slot no longer
>> retains the required WAL files and some of them are to be removed at
>> - the next checkpoint. This state can return
>> + the next checkpoint. This can occur when
>> + <xref linkend="guc-max-slot-wal-keep-size"/> is set to
>> + a non-negative value. This state can return
>> to <literal>reserved</literal> or <literal>extended</literal>.
>> </para>
>> </listitem>
>> <listitem>
>> ----------------------
>>
>> What do you think?
>>
>
> The change LGTM, only a minor suggestion to add "typically", as “This
> can typically occur when…” to indicate that max_slot_wal_keep_size is
> one possible reason, not the only one.
OK.
>> Also, I noticed the note that says “If <structfield>restart_lsn</structfield>
>> is NULL, this field is null” seems inaccurate. For example, when "wal_removed"
>> happens, restart_lsn is NULL but wal_status is "lost". So maybe we should remove
>> that note as well?
>
> You're right, the statement is not accurate.
> We could rephrase it as: "If <structfield>restart_lsn</structfield> is
> NULL, this field is either null or lost." But since 'unreserved' can
> also appear briefly during invalidation, it might be better to remove
> it altogether.
I agree with removing the description. Unless I'm missing something,
it has been incorrect since at least v13, so we should back-patch this fix
to all supported versions.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Mention idle_replication_slot_timeout in pg_replication_slots docs
@ 2025-07-01 04:52 Nisha Moond <nisha.moond412@gmail.com>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 1 reply; 13+ messages in thread
From: Nisha Moond @ 2025-07-01 04:52 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; +Cc: pgsql-docs@lists.postgresql.org
On Mon, Jun 30, 2025 at 6:12 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>
>
>
> On 2025/06/30 20:32, Nisha Moond wrote:
> > On Fri, Jun 27, 2025 at 5:40 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> >>
> >>
> >>
> >> On 2025/06/27 15:32, Nisha Moond wrote:
> >>> On Thu, Jun 26, 2025 at 1:33 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 2025/06/26 15:46, Nisha Moond wrote:
> >>>>> On Wed, Jun 25, 2025 at 9:56 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> The pg_replication_slots documentation mentions only max_slot_wal_keep_size
> >>>>>> as a condition under which the wal_status column can show unreserved or lost.
> >>>>>> However, since commit ac0e33136ab, idle_replication_slot_timeout can also
> >>>>>> cause this behavior when it is set. This has not been documented yet.
> >>>>>> https://www.postgresql.org/docs/devel/view-pg-replication-slots.html
> >>>>>>
> >>>>>
> >>>>> +1 to the doc update.
> >>>>
> >>>> Thanks for the review!
> >>>>
> >>>>
> >>>>>> So, how about updating the documentation to also mention
> >>>>>> idle_replication_slot_timeout as a factor that can cause wal_status to
> >>>>>> become unreserved or lost? Patch attached.
> >>>>>>
> >>>>>
> >>>>> Since idle_replication_slot_timeout can only cause wal_status to
> >>>>> become 'lost' and not 'unreserved', perhaps we can reword the sentence
> >>>>> slightly for clarity, suggestion -
> >>>>> "The last two states are seen when max_slot_wal_keep_size is
> >>>>> non-negative and, the 'lost' state may also appear when
> >>>>> idle_replication_slot_timeout is greater than zero."
> >>>>
> >>>> I was thinking that when idle_replication_slot_timeout triggers,
> >>>> the following functions are called, and that wal_status can become
> >>>> "unreserved" before ReplicationSlotRelease() runs. It's very short
> >>>> period, though. Am I wrong?
> >>>>
> >>>> ReplicationSlotMarkDirty();
> >>>> ReplicationSlotSave();
> >>>> ReplicationSlotRelease();
> >>>>
> >>>
> >>> Thank you for pointing it out.
> >>> You are correct that while the checkpointer is in the process of
> >>> invalidating a slot, it sets its PID as the slot’s active_pid. During
> >>> this short window, if a user queries pg_replication_slot, the
> >>> underlying function pg_get_replication_slots will compute the
> >>> wal_status as 'unreserved' for the invalidated slot because the slot
> >>> has a valid active_pid.
> >>>
> >>> That said, it's reasonable to mention in the doc that 'unreserved' may
> >>> appear when idle_replication_slot_timeout is greater than zero, as
> >>> this can indeed happen. So, let's retain the current description.
> >>>
> >>> However, this behavior isn’t specific to
> >>> idle_replication_slot_timeout. For example, when a slot is being
> >>> invalidated due to a different cause "wal_level_insufficient",
> >>> 'unreserved' may also briefly appear in wal_status.
> >>
> >> Yes, and "lost" can appear for various reasons, including wal_level_insufficient,
> >> so it seems odd to highlight max_slot_wal_keep_size as the cause of the "lost"
> >> status in the note. It would probably be better to remove the mention of "lost"
> >> from that note.
> >>
> >
> > +1
>
> 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.
--
Thanks,
Nisha
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Mention idle_replication_slot_timeout in pg_replication_slots docs
@ 2025-07-02 07:12 Fujii Masao <masao.fujii@oss.nttdata.com>
parent: Nisha Moond <nisha.moond412@gmail.com>
0 siblings, 1 reply; 13+ messages in thread
From: Fujii Masao @ 2025-07-02 07:12 UTC (permalink / raw)
To: Nisha Moond <nisha.moond412@gmail.com>; +Cc: pgsql-docs@lists.postgresql.org
On 2025/07/01 13:52, Nisha Moond wrote:
> On Mon, Jun 30, 2025 at 6:12 PM Fujii Masao <masao.fujii@oss.nttdata.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.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
From d8b9c1aace3f21bc916d905380894376bb3c7a6f Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Wed, 2 Jul 2025 15:37:53 +0900
Subject: [PATCH v3 1/2] doc: Remove incorrect note about wal_status in
pg_replication_slots.
The documentation previously stated that the wal_status column is NULL
if restart_lsn is NULL in the pg_replication_slots view. This is incorrect,
and wal_status can be "lost" even when restart_lsn is NULL.
This commit removes the incorrect description.
Back-patched to all supported versions.
Author: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: Nisha Moond <nisha.moond412@gmail.com>
Discussion: https://postgr.es/m/c9d23cdc-b5dd-455a-8ee9-f1f24d701d89@oss.nttdata.com
Backpatch-through: 13
---
doc/src/sgml/system-views.sgml | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml
index 986ae1f543d..82825db03bb 100644
--- a/doc/src/sgml/system-views.sgml
+++ b/doc/src/sgml/system-views.sgml
@@ -2832,8 +2832,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
</itemizedlist>
The last two states are seen only when
<xref linkend="guc-max-slot-wal-keep-size"/> is
- non-negative. If <structfield>restart_lsn</structfield> is NULL, this
- field is null.
+ non-negative.
</para></entry>
</row>
--
2.49.0
From 320e208e4443eb2c89f777ef990f6653628589b4 Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Wed, 2 Jul 2025 16:02:29 +0900
Subject: [PATCH v3 2/2] doc: Update outdated descriptions of wal_status in
pg_replication_slots.
The documentation for pg_replication_slots previously mentioned only
max_slot_wal_keep_size as a condition under which the wal_status column
could show unreserved or lost. However, since commit be87200,
replication slots can also be invalidated due to horizon or wal_level,
and since commit ac0e33136ab, idle_replication_slot_timeout can also
trigger this state.
This commit updates the description of the wal_status column to
reflect that max_slot_wal_keep_size is not the only cause of the lost state.
Back-patched to v16, where the additional invalidation cases were introduced.
Author: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>
Reviewed-by: Nisha Moond <nisha.moond412@gmail.com>
Discussion: https://postgr.es/m/78b34e84-2195-4f28-a151-5d204a382fdd@oss.nttdata.com
Backpatch-through: 17
---
doc/src/sgml/system-views.sgml | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml
index 82825db03bb..e1ac544ee40 100644
--- a/doc/src/sgml/system-views.sgml
+++ b/doc/src/sgml/system-views.sgml
@@ -2819,20 +2819,18 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
<para>
<literal>unreserved</literal> means that the slot no longer
retains the required WAL files and some of them are to be removed at
- the next checkpoint. This state can return
+ the next checkpoint. This typically occurs when
+ <xref linkend="guc-max-slot-wal-keep-size"/> is set to
+ a non-negative value. This state can return
to <literal>reserved</literal> or <literal>extended</literal>.
</para>
</listitem>
<listitem>
<para>
- <literal>lost</literal> means that some required WAL files have
- been removed and this slot is no longer usable.
+ <literal>lost</literal> means that this slot is no longer usable.
</para>
</listitem>
</itemizedlist>
- The last two states are seen only when
- <xref linkend="guc-max-slot-wal-keep-size"/> is
- non-negative.
</para></entry>
</row>
--
2.49.0
Attachments:
[text/plain] v3-0001-doc-Remove-incorrect-note-about-wal_status-in-pg_.patch (1.4K, ../../95d064d7-9902-436c-a4d2-a1155e4208c2@oss.nttdata.com/2-v3-0001-doc-Remove-incorrect-note-about-wal_status-in-pg_.patch)
download | inline diff:
From d8b9c1aace3f21bc916d905380894376bb3c7a6f Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Wed, 2 Jul 2025 15:37:53 +0900
Subject: [PATCH v3 1/2] doc: Remove incorrect note about wal_status in
pg_replication_slots.
The documentation previously stated that the wal_status column is NULL
if restart_lsn is NULL in the pg_replication_slots view. This is incorrect,
and wal_status can be "lost" even when restart_lsn is NULL.
This commit removes the incorrect description.
Back-patched to all supported versions.
Author: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: Nisha Moond <nisha.moond412@gmail.com>
Discussion: https://postgr.es/m/c9d23cdc-b5dd-455a-8ee9-f1f24d701d89@oss.nttdata.com
Backpatch-through: 13
---
doc/src/sgml/system-views.sgml | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml
index 986ae1f543d..82825db03bb 100644
--- a/doc/src/sgml/system-views.sgml
+++ b/doc/src/sgml/system-views.sgml
@@ -2832,8 +2832,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
</itemizedlist>
The last two states are seen only when
<xref linkend="guc-max-slot-wal-keep-size"/> is
- non-negative. If <structfield>restart_lsn</structfield> is NULL, this
- field is null.
+ non-negative.
</para></entry>
</row>
--
2.49.0
[text/plain] v3-0002-doc-Update-outdated-descriptions-of-wal_status-in.patch (2.4K, ../../95d064d7-9902-436c-a4d2-a1155e4208c2@oss.nttdata.com/3-v3-0002-doc-Update-outdated-descriptions-of-wal_status-in.patch)
download | inline diff:
From 320e208e4443eb2c89f777ef990f6653628589b4 Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Wed, 2 Jul 2025 16:02:29 +0900
Subject: [PATCH v3 2/2] doc: Update outdated descriptions of wal_status in
pg_replication_slots.
The documentation for pg_replication_slots previously mentioned only
max_slot_wal_keep_size as a condition under which the wal_status column
could show unreserved or lost. However, since commit be87200,
replication slots can also be invalidated due to horizon or wal_level,
and since commit ac0e33136ab, idle_replication_slot_timeout can also
trigger this state.
This commit updates the description of the wal_status column to
reflect that max_slot_wal_keep_size is not the only cause of the lost state.
Back-patched to v16, where the additional invalidation cases were introduced.
Author: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: Hayato Kuroda <kuroda.hayato@fujitsu.com>
Reviewed-by: Nisha Moond <nisha.moond412@gmail.com>
Discussion: https://postgr.es/m/78b34e84-2195-4f28-a151-5d204a382fdd@oss.nttdata.com
Backpatch-through: 17
---
doc/src/sgml/system-views.sgml | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml
index 82825db03bb..e1ac544ee40 100644
--- a/doc/src/sgml/system-views.sgml
+++ b/doc/src/sgml/system-views.sgml
@@ -2819,20 +2819,18 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
<para>
<literal>unreserved</literal> means that the slot no longer
retains the required WAL files and some of them are to be removed at
- the next checkpoint. This state can return
+ the next checkpoint. This typically occurs when
+ <xref linkend="guc-max-slot-wal-keep-size"/> is set to
+ a non-negative value. This state can return
to <literal>reserved</literal> or <literal>extended</literal>.
</para>
</listitem>
<listitem>
<para>
- <literal>lost</literal> means that some required WAL files have
- been removed and this slot is no longer usable.
+ <literal>lost</literal> means that this slot is no longer usable.
</para>
</listitem>
</itemizedlist>
- The last two states are seen only when
- <xref linkend="guc-max-slot-wal-keep-size"/> is
- non-negative.
</para></entry>
</row>
--
2.49.0
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: Mention idle_replication_slot_timeout in pg_replication_slots docs
@ 2025-07-03 14:13 Fujii Masao <masao.fujii@oss.nttdata.com>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 0 replies; 13+ messages in thread
From: Fujii Masao @ 2025-07-03 14:13 UTC (permalink / raw)
To: Nisha Moond <nisha.moond412@gmail.com>; +Cc: pgsql-docs@lists.postgresql.org
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.fujii@oss.nttdata.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
^ permalink raw reply [nested|flat] 13+ messages in thread
end of thread, other threads:[~2025-07-03 14:13 UTC | newest]
Thread overview: 13+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-06-25 16:25 Mention idle_replication_slot_timeout in pg_replication_slots docs Fujii Masao <masao.fujii@oss.nttdata.com>
2025-06-26 06:43 ` Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
2025-06-26 07:55 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2025-06-27 05:03 ` Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
2025-06-26 06:46 ` Nisha Moond <nisha.moond412@gmail.com>
2025-06-26 08:03 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2025-06-27 06:32 ` Nisha Moond <nisha.moond412@gmail.com>
2025-06-27 12:10 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2025-06-30 11:32 ` Nisha Moond <nisha.moond412@gmail.com>
2025-06-30 12:42 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2025-07-01 04:52 ` Nisha Moond <nisha.moond412@gmail.com>
2025-07-02 07:12 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2025-07-03 14:13 ` Fujii Masao <masao.fujii@oss.nttdata.com>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox