pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedThe description for pg_replication_slots.restart_lsn
5+ messages / 2 participants
[nested] [flat]
Commits from this thread:
2020-07-03 8f9b6d4057 95a604eaeb doc: Correct description of restart_lsn in pg_replication_slots
* The description for pg_replication_slots.restart_lsn
@ 2020-06-17 14:47 Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 2 replies; 5+ messages in thread
From: Fujii Masao @ 2020-06-17 14:47 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org
Hi,
The document explains that restart_lsn column in pg_replication_slots view is:
The address (LSN) of oldest WAL which still might be required by
the consumer of this slot and thus won't be automatically removed
during checkpoints.
But the latter part is not true in v13 thanks to max_slot_wal_keep_size.
I think that we need to update it as follows. Thought?
The address (LSN) of oldest WAL which still might be required by
the consumer of this slot and thus won't be automatically removed
during checkpoints unless this LSN gets behind more than
max_slot_wal_keep_size from the current LSN.
Patch attached.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Attachments:
pg_replication_slots_restart_lsn.patch (text/plain, 793B) download
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 700271fd40..bf326cf533 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -11214,7 +11214,9 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
<para>
The address (<literal>LSN</literal>) of oldest WAL which still
might be required by the consumer of this slot and thus won't be
- automatically removed during checkpoints. <literal>NULL</literal>
+ automatically removed during checkpoints unless this LSN
+ gets behind more than <xref linkend="guc-max-slot-wal-keep-size"/>
+ from the current LSN. <literal>NULL</literal>
if the <literal>LSN</literal> of this slot has never been reserved.
</para></entry>
</row>
* Re: The description for pg_replication_slots.restart_lsn
@ 2020-06-25 00:42 Fujii Masao <masao.fujii@oss.nttdata.com>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
1 sibling, 0 replies; 5+ messages in thread
From: Fujii Masao @ 2020-06-25 00:42 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org
On 2020/06/17 23:47, Fujii Masao wrote:
> Hi,
>
> The document explains that restart_lsn column in pg_replication_slots view is:
>
> The address (LSN) of oldest WAL which still might be required by
> the consumer of this slot and thus won't be automatically removed
> during checkpoints.
>
> But the latter part is not true in v13 thanks to max_slot_wal_keep_size.
> I think that we need to update it as follows. Thought?
>
> The address (LSN) of oldest WAL which still might be required by
> the consumer of this slot and thus won't be automatically removed
> during checkpoints unless this LSN gets behind more than
> max_slot_wal_keep_size from the current LSN.
>
> Patch attached.
Barring any objection, I will commit this patch.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: The description for pg_replication_slots.restart_lsn
@ 2020-06-25 01:00 Alvaro Herrera <alvherre@2ndquadrant.com>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
1 sibling, 1 reply; 5+ messages in thread
From: Alvaro Herrera @ 2020-06-25 01:00 UTC (permalink / raw)
To: Fujii Masao <masao.fujii@oss.nttdata.com>; +Cc: pgsql-docs@lists.postgresql.org
On 2020-Jun-17, Fujii Masao wrote:
> The document explains that restart_lsn column in pg_replication_slots view is:
>
> The address (LSN) of oldest WAL which still might be required by
> the consumer of this slot and thus won't be automatically removed
> during checkpoints.
>
> But the latter part is not true in v13 thanks to max_slot_wal_keep_size.
> I think that we need to update it as follows. Thought?
>
> The address (LSN) of oldest WAL which still might be required by
> the consumer of this slot and thus won't be automatically removed
> during checkpoints unless this LSN gets behind more than
> max_slot_wal_keep_size from the current LSN.
We just added the invalidated_at LSN to replication slots; while working
on the tests for that today, I was thinking that it might be useful to
display that LSN in pg_replication_slots. What do you think of the idea
of publishing the invalidated_at LSN in pg_replication_slot.restart_lsn
when the slot is invalid?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: The description for pg_replication_slots.restart_lsn
@ 2020-06-25 05:48 Fujii Masao <masao.fujii@oss.nttdata.com>
parent: Alvaro Herrera <alvherre@2ndquadrant.com>
0 siblings, 1 reply; 5+ messages in thread
From: Fujii Masao @ 2020-06-25 05:48 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: pgsql-docs@lists.postgresql.org
On 2020/06/25 10:00, Alvaro Herrera wrote:
> On 2020-Jun-17, Fujii Masao wrote:
>
>> The document explains that restart_lsn column in pg_replication_slots view is:
>>
>> The address (LSN) of oldest WAL which still might be required by
>> the consumer of this slot and thus won't be automatically removed
>> during checkpoints.
>>
>> But the latter part is not true in v13 thanks to max_slot_wal_keep_size.
>> I think that we need to update it as follows. Thought?
>>
>> The address (LSN) of oldest WAL which still might be required by
>> the consumer of this slot and thus won't be automatically removed
>> during checkpoints unless this LSN gets behind more than
>> max_slot_wal_keep_size from the current LSN.
>
> We just added the invalidated_at LSN to replication slots; while working
> on the tests for that today, I was thinking that it might be useful to
> display that LSN in pg_replication_slots. What do you think of the idea
> of publishing the invalidated_at LSN in pg_replication_slot.restart_lsn
> when the slot is invalid?
I like having separate column for invalidated_at because (at least for me)
it's a bit confusing to report the different meaning values in the same column
depending on the state.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: The description for pg_replication_slots.restart_lsn
@ 2020-06-30 05:56 Fujii Masao <masao.fujii@oss.nttdata.com>
parent: Fujii Masao <masao.fujii@oss.nttdata.com>
0 siblings, 0 replies; 5+ messages in thread
From: Fujii Masao @ 2020-06-30 05:56 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@2ndquadrant.com>; +Cc: pgsql-docs@lists.postgresql.org
On 2020/06/25 14:48, Fujii Masao wrote:
>
>
> On 2020/06/25 10:00, Alvaro Herrera wrote:
>> On 2020-Jun-17, Fujii Masao wrote:
>>
>>> The document explains that restart_lsn column in pg_replication_slots view is:
>>>
>>> The address (LSN) of oldest WAL which still might be required by
>>> the consumer of this slot and thus won't be automatically removed
>>> during checkpoints.
>>>
>>> But the latter part is not true in v13 thanks to max_slot_wal_keep_size.
>>> I think that we need to update it as follows. Thought?
>>>
>>> The address (LSN) of oldest WAL which still might be required by
>>> the consumer of this slot and thus won't be automatically removed
>>> during checkpoints unless this LSN gets behind more than
>>> max_slot_wal_keep_size from the current LSN.
>>
>> We just added the invalidated_at LSN to replication slots; while working
>> on the tests for that today, I was thinking that it might be useful to
>> display that LSN in pg_replication_slots. What do you think of the idea
>> of publishing the invalidated_at LSN in pg_replication_slot.restart_lsn
>> when the slot is invalid?
>
> I like having separate column for invalidated_at because (at least for me)
> it's a bit confusing to report the different meaning values in the same column
> depending on the state.
Is there any other objection to the patch? If nothing, I'd like to push it.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2020-06-30 05:56 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-06-17 14:47 The description for pg_replication_slots.restart_lsn Fujii Masao <masao.fujii@oss.nttdata.com>
2020-06-25 00:42 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2020-06-25 01:00 ` Alvaro Herrera <alvherre@2ndquadrant.com>
2020-06-25 05:48 ` Fujii Masao <masao.fujii@oss.nttdata.com>
2020-06-30 05:56 ` Fujii Masao <masao.fujii@oss.nttdata.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox