Re: [HACKERS] Restricting maximum keep segments by repslots
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Restricting maximum keep segments by repslots |
Дата | |
Msg-id | CA+TgmoaNJbMCxKZAAZkgcrxyg81QF9eT9CGM0iWFd2mxQ2b6sA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Restricting maximum keep segments by repslots (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
On Tue, Feb 28, 2017 at 10:04 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > It would make more sense to just switch max_wal_size from a soft to a > hard limit. The current behavior is not cool with activity spikes. Having a hard limit on WAL size would be nice, but that's a different problem from the one being discussed here. If max_wal_size becomes a hard limit, and a standby with a replication slot dies, then the master eventually starts refusing all writes. I guess that's better than a PANIC, but it's not likely to make users very happy. I think it's entirely reasonable to want a behavior where the master is willing to retain up to X amount of extra WAL for the benefit of some standby, but after that the health of the master takes priority. You can't really get that behavior today. Either you can retain as much WAL as might be necessary through archiving or a slot, or you can retain a fixed amount of WAL whether it's actually needed or not. There's currently no approach that retains min(wal_needed, configured_value). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: