From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: The description for pg_replication_slots.restart_lsn |
Date: | 2020-06-30 05:56:50 |
Message-ID: | b495e29a-4131-81f6-7d0d-dcbb51cc5152@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2020-06-30 16:28:07 | Re: INDEX with optional storage parameter value |
Previous Message | Peter Geoghegan | 2020-06-29 21:46:38 | Re: Default setting for enable_hashagg_disk |