Re: Restricting maximum keep segments by repslots

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hello, this is a rebased version.

It gets a change of the meaning of monitoring value along with

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

- 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.


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

In response to


Browse pgsql-hackers by date

  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