Re: The description for pg_replication_slots.restart_lsn

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-07-03 03:10:03
Message-ID: 58dfb2f6-c1b1-5edc-8194-51fc2130edb6@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

On 2020/06/30 14:56, Fujii Masao wrote:
>
>
> 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.

Pushed. Thanks!

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message Peter Geoghegan 2020-07-03 03:35:40 Re: Default setting for enable_hashagg_disk (hash_mem)
Previous Message Bruce Momjian 2020-07-03 03:00:01 Re: Default setting for enable_hashagg_disk (hash_mem)