Re: [HACKERS] Restricting maximum keep segments by repslots
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] Restricting maximum keep segments by repslots |
Дата | |
Msg-id | 20180731192413.7lr4qbc4qbyoim5y@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Restricting maximum keep segments by repslots (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: [HACKERS] Restricting maximum keep segments by repslots
|
Список | pgsql-hackers |
On 2018-07-31 15:21:27 -0400, Stephen Frost wrote: > Greetings, > > * Andres Freund (andres@anarazel.de) wrote: > > On 2018-07-31 15:11:52 -0400, Bruce Momjian wrote: > > > On Tue, Jun 26, 2018 at 04:26:59PM +0900, Kyotaro HORIGUCHI wrote: > > > > Hello. This is the reabased version of slot-limit feature. > > > > > > > > This patch limits maximum WAL segments to be kept by replication > > > > slots. Replication slot is useful to avoid desync with replicas > > > > after temporary disconnection but it is dangerous when some of > > > > replicas are lost. The WAL space can be exhausted and server can > > > > PANIC in the worst case. This can prevent the worst case having a > > > > benefit from replication slots using a new GUC variable > > > > max_slot_wal_keep_size. > > > > > > Have you considered just using a boolean to control if max_wal_size > > > honors WAL preserved by replication slots, rather than creating the new > > > GUC max_slot_wal_keep_size? > > > > That seems like a bad idea. max_wal_size influences checkpoint > > scheduling - there's no good reason to conflate that with retention? > > I agree that we shouldn't conflate checkpointing and retention. What I > wonder about though is what value will wal_keep_segments have once this > new GUC exists..? I wonder if we could deprecate it... Don't think that's a good idea. It's entirely conceivable to have a wal_keep_segments much lower than max_slot_wal_keep_size. For some throwaway things it can be annoying to have to slots, and if you remove wal_keep_segments there's no alternative. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: