|From:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|To:||Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>|
|Cc:||jgdr(at)dalibo(dot)com, andres(at)anarazel(dot)de, michael(at)paquier(dot)xyz, sawada(dot)mshk(at)gmail(dot)com, peter(dot)eisentraut(at)2ndquadrant(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, thomas(dot)munro(at)enterprisedb(dot)com, sk(at)zsrv(dot)org, michael(dot)paquier(at)gmail(dot)com|
|Subject:||Re: [HACKERS] Restricting maximum keep segments by repslots|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2020-Apr-06, Kyotaro Horiguchi wrote:
> > * Andres complained that the "distance" column was not a great value to
> > expose (20171106132050(dot)6apzynxrqrzghb4r(at)alap3(dot)anarazel(dot)de). That's
> > right: it changes both by the insertion LSN as well as the slot's
> > consumption. Maybe we can expose the earliest live LSN (start of the
> > earliest segment?) as a new column. It'll be the same for all slots,
> > I suppose, but we don't care, do we?
> I don't care as far as users can calculate the "remain" of individual
> slots (that is, how far the current LSN can advance before the slot
> loses data). But the "earliest live LSN (EL-LSN) is really not
> relevant to the safeness of each slot. The distance from EL-LSN to
> restart_lsn or the current LSN doesn't generally suggest the safeness
> of individual slots. The only relevance would be if the distance from
> EL-LSN to the current LSN is close to max_slot_wal_keep_size, the most
> lagged slot could die in a short term.
Thanks for the revised version. Please note that you forgot to "git
add" the test file, to it's not in the patch.
I'm reviewing the patch now.
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
|Next Message||Magnus Hagander||2020-04-06 17:32:45||Re: where should I stick that backup?|
|Previous Message||Anastasia Lubennikova||2020-04-06 16:40:39||Re: pg_upgrade fails with non-standard ACL|