From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | peter(dot)eisentraut(at)2ndquadrant(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Restricting maximum keep segments by repslots |
Date: | 2017-10-31 09:43:10 |
Message-ID: | 20171031.184310.182012625.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello, this is a rebased version.
It gets a change of the meaning of monitoring value along with
rebasing.
In previous version, the "live" column mysteriously predicts the
necessary segments will be kept or lost by the next checkpoint
and the "distance" offered a still more mysterious value.
In this version the meaning of the two columns became clear and
informative.
pg_replication_slots
- live :
true the slot have not lost necessary segments.
- distance:
how many bytes LSN can advance before the margin defined by
max_slot_wal_keep_size (and wal_keep_segments) is exhasuted,
or how many bytes this slot have lost xlog from restart_lsn.
There is a case where live = t and distance = 0. The slot is
currently having all the necessary segments but will start to
lose them at most two checkpoint passes.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
0001-Add-WAL-releaf-vent-for-replication-slots.patch | text/x-patch | 3.9 KB |
0002-Add-monitoring-aid-for-max_replication_slots.patch | text/x-patch | 9.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2017-10-31 09:46:22 | Re: Protect syscache from bloating with negative cache entries |
Previous Message | Robert Haas | 2017-10-31 09:30:11 | Re: EXPLAIN (ANALYZE, BUFFERS) reports bogus temporary buffer reads |