Thread
Commits
-
doc: Correct description of restart_lsn in pg_replication_slots
- 95a604eaebd1 13.0 landed
- 8f9b6d40570b 14.0 landed
-
The description for pg_replication_slots.restart_lsn
Fujii Masao <masao.fujii@oss.nttdata.com> — 2020-06-17T14:47:28Z
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 -
Re: The description for pg_replication_slots.restart_lsn
Fujii Masao <masao.fujii@oss.nttdata.com> — 2020-06-25T00:42:47Z
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
-
Re: The description for pg_replication_slots.restart_lsn
Alvaro Herrera <alvherre@2ndquadrant.com> — 2020-06-25T01:00:16Z
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
-
Re: The description for pg_replication_slots.restart_lsn
Fujii Masao <masao.fujii@oss.nttdata.com> — 2020-06-25T05:48:18Z
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
-
Re: The description for pg_replication_slots.restart_lsn
Fujii Masao <masao.fujii@oss.nttdata.com> — 2020-06-30T05:56:50Z
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
-
Re: The description for pg_replication_slots.restart_lsn
Fujii Masao <masao.fujii@oss.nttdata.com> — 2020-07-03T03:10:03Z
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