Thread: The description for pg_replication_slots.restart_lsn
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
Attachment
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
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
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
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
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