From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | sk(at)zsrv(dot)org |
Cc: | michael(dot)paquier(at)gmail(dot)com, andres(at)anarazel(dot)de, peter(dot)eisentraut(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Restricting maximum keep segments by repslots |
Date: | 2018-01-11 06:59:10 |
Message-ID: | 20180111.155910.26212237.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello. Thank you for the comment.
(And sorry for the absense.)
At Fri, 22 Dec 2017 15:04:20 +0300, Sergei Kornilov <sk(at)zsrv(dot)org> wrote in <337571513944260(at)web55j(dot)yandex(dot)ru>
> Hello
> I think limit wal in replication slots is useful in some cases. But first time i was confused with proposed terminology secured/insecured/broken/unknown state.
I'm not confident on the terminology. Suggestions are welcome on
the wording that makes more sense.
> patch -p1 gives some "Stripping trailing CRs from patch"
> messages for me, but applied to current HEAD and builds. After
Hmm. I wonder why I get that complaint so often. (It's rather
common? or caused by the MIME format of my mail?) I'd say with
confidence that it is because you retrieved the patch file on
Windows mailer.
> little testing i understood the difference in
> secured/insecured/broken terminology. Secured means garantee to
> keep wal, insecure - wal may be deleted with next checkpoint,
> broken - wal already deleted.
Right. I'm sorry that I haven't written that clearly anywhere and
bothered you confirming that. I added documentation as the forth
patch.
> I think, we may split "secure" to "streaming"
> and... hmm... "waiting"? "keeping"? - according active flag for
> clarify and readable "status" field.
streaming / keeping and lost? (and unknown) Also "status" is
surely offers somewhat obscure meaning. wal_status (or
(wal_)availability) and min_keep_lsn maeke more sense?
The additional fields in pg_replication_slots have been changed
as the follows in the attached patch.
confirmed_flush_lsn:
+ wal_status : (streaming | keeping | lost | unknown)
+ min_keep_lsn : <The oldest LSN that is available in WAL files>
The changes of documentation are seen in the following html files.
doc/src/sgml/html/warm-standby.html#STREAMING-REPLICATION-SLOTS
doc/src/sgml/html/runtime-config-replication.html#GUC-MAX-SLOT-WAL-KEEP-SIZE
doc/src/sgml/html/view-pg-replication-slots.html
One annoyance is that the min_keep_lsn always has the same value
among all slots.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
0001-Add-WAL-releaf-vent-for-replication-slots.patch | text/x-patch | 6.9 KB |
0002-Add-monitoring-aid-for-max_replication_slots.patch | text/x-patch | 8.3 KB |
0003-TAP-test-for-the-slot-limit-feature.patch | text/x-patch | 5.3 KB |
0004-Documentation-for-slot-limit-feature.patch | text/x-patch | 5.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-01-11 07:07:52 | Re: numeric regression test passes, but why? |
Previous Message | Michael Paquier | 2018-01-11 06:49:00 | pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs |