Re: Hard limit on WAL space used (because PANIC sucks)
От | Joshua D. Drake |
---|---|
Тема | Re: Hard limit on WAL space used (because PANIC sucks) |
Дата | |
Msg-id | 51B16A63.3030404@commandprompt.com обсуждение исходный текст |
Ответ на | Re: Hard limit on WAL space used (because PANIC sucks) (Jeff Janes <jeff.janes@gmail.com>) |
Список | pgsql-hackers |
On 06/06/2013 09:30 PM, Jeff Janes wrote: > Archiving > --------- > > In some ways, this is the simplest case. Really, we just need a way to > know when the available WAL space has become 90% full, and abort > archiving at that stage. Once we stop attempting to archive, we can > clean up the unneeded log segments. > > > I would oppose that as the solution, either an unconditional one, or > configurable with is it as the default. Those segments are not > unneeded. I need them. That is why I set up archiving in the first > place. If you need to shut down the database rather than violate my > established retention policy, then shut down the database. Agreed and I would oppose it even as configurable. We set up the archiving for a reason. I do think it might be useful to be able to store archiving logs as well as wal_keep_segments logs in a different location than pg_xlog. > > What we need is a better way for the DBA to find out that archiving is > falling behind when it first starts to fall behind. Tailing the log and > examining the rather cryptic error messages we give out isn't very > effective. > > > The archive command can be made a shell script (or that matter a > compiled program) which can do anything it wants upon failure, including > emailing people. Yep, that is what PITRTools does. You can make it do whatever you want. JD
В списке pgsql-hackers по дате отправления: