Re: [HACKERS] Restricting maximum keep segments by repslots
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: [HACKERS] Restricting maximum keep segments by repslots |
Дата | |
Msg-id | 20190222.101251.03333542.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Restricting maximum keep segments by repslots (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] Restricting maximum keep segments by repslots
|
Список | pgsql-hackers |
At Fri, 15 Feb 2019 19:13:23 -0800, Andres Freund <andres@anarazel.de> wrote in <20190216031323.t7tfrae4l6zqtseo@alap3.anarazel.de> > Hi, > > On 2019-01-30 10:42:04 +0900, Kyotaro HORIGUCHI wrote: > > From 270aff9b08ced425b4c4e23b53193285eb2359a6 Mon Sep 17 00:00:00 2001 > > From: Kyotaro Horiguchi <horiguchi.kyotaro@lab.ntt.co.jp> > > Date: Thu, 21 Dec 2017 21:20:20 +0900 > > Subject: [PATCH 1/6] Add WAL relief vent for replication slots > > > > Adds a capability to limit the number of segments kept by replication > > slots by a GUC variable. > > Maybe I'm missing something, but how does this prevent issues with > active slots that are currently accessing the WAL this patch now > suddenly allows to be removed? Especially for logical slots that seems > not unproblematic? No matter whether logical or physical, when reading an overwritten page of a recycled/renamed segment file, page validation at reading-in finds that it is of a different segment than expected. 0006 in [1] introduces more active checking on that. [1] https://www.postgresql.org/message-id/20181220.162438.121484007.horiguchi.kyotaro%40lab.ntt.co.jp > Besides that, this patch needs substantial spelling / language / comment > polishing. Horiguchi-san, it'd probably be good if you could make a > careful pass, and then maybe a native speaker could go over it? Thank you for your kind suggestion. As I did for other patches, I'll review it by myself and come up with a new version soon. # I often don't understand what I wrote:( regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: