The description for pg_replication_slots.restart_lsn

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

The description for pg_replication_slots.restart_lsn

Fujii Masao-4
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

pg_replication_slots_restart_lsn.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The description for pg_replication_slots.restart_lsn

Fujii Masao-4


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


Reply | Threaded
Open this post in threaded view
|

Re: The description for pg_replication_slots.restart_lsn

Alvaro Herrera-9
In reply to this post by Fujii Masao-4
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


Reply | Threaded
Open this post in threaded view
|

Re: The description for pg_replication_slots.restart_lsn

Fujii Masao-4


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


Reply | Threaded
Open this post in threaded view
|

Re: The description for pg_replication_slots.restart_lsn

Fujii Masao-4


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


Reply | Threaded
Open this post in threaded view
|

Re: The description for pg_replication_slots.restart_lsn

Fujii Masao-4


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