Subject: Re: The description for pg_replication_slots.restart_lsn
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: pgsql-docs@lists.postgresql.org
References: <20200625010016.GA22779@alvherre.pgsql>
 <0414a23a-974c-04d5-ccb0-70ebcc76fcb7@oss.nttdata.com>
Message-ID: <b495e29a-4131-81f6-7d0d-dcbb51cc5152@oss.nttdata.com>
Date: Tue, 30 Jun 2020 14:56:50 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <0414a23a-974c-04d5-ccb0-70ebcc76fcb7@oss.nttdata.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk


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