| From: | Sergei Kornilov <sk(at)zsrv(dot)org> |
|---|---|
| To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "michael(dot)paquier(at)gmail(dot)com" <michael(dot)paquier(at)gmail(dot)com> |
| Cc: | "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "peter(dot)eisentraut(at)2ndquadrant(dot)com" <peter(dot)eisentraut(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] Restricting maximum keep segments by repslots |
| Date: | 2017-12-22 12:04:20 |
| Message-ID: | 337571513944260@web55j.yandex.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
patch -p1 gives some "Stripping trailing CRs from patch" messages for me, but applied to current HEAD and builds. After 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.
I think, we may split "secure" to "streaming" and... hmm... "waiting"? "keeping"? - according active flag for clarify and readable "status" field.
regards, Sergei
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Maksim Milyutin | 2017-12-22 12:05:25 | [HACKERS] PoC: custom signal handler for extensions |
| Previous Message | Dilip Kumar | 2017-12-22 11:28:47 | Re: After dropping the rule - Not able to insert / server crash (one time ONLY) |