Re: Hard limit on WAL space used (because PANIC sucks)
От | Jim Nasby |
---|---|
Тема | Re: Hard limit on WAL space used (because PANIC sucks) |
Дата | |
Msg-id | 52E0600D.7040007@nasby.net обсуждение исходный текст |
Ответ на | Re: Hard limit on WAL space used (because PANIC sucks) (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Hard limit on WAL space used (because PANIC sucks)
Re: Hard limit on WAL space used (because PANIC sucks) |
Список | pgsql-hackers |
On 1/21/14, 6:46 PM, Andres Freund wrote: > On 2014-01-21 16:34:45 -0800, Peter Geoghegan wrote: >> >On Tue, Jan 21, 2014 at 3:43 PM, Andres Freund<andres@2ndquadrant.com> wrote: >>> > >I personally think this isn't worth complicating the code for. >> > >> >You're probably right. However, I don't see why the bar has to be very >> >high when we're considering the trade-off between taking some >> >emergency precaution against having a PANIC shutdown, and an assured >> >PANIC shutdown > Well, the problem is that the tradeoff would very likely include making > already complex code even more complex. None of the proposals, even the > one just decreasing the likelihood of a PANIC, like like they'd end up > being simple implementation-wise. > And that additional complexity would hurt robustness and prevent things > I find much more important than this. If we're not looking for perfection, what's wrong with Peter's idea of a ballast file? Presumably the check to see if thatfile still exists would be cheap so we can do that before entering the appropriate critical section. There's still a small chance that we'd end up panicing, but it's better than today. I'd argue that even if it doesn't workfor CoW filesystems it'd still be a win. -- Jim C. Nasby, Data Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
В списке pgsql-hackers по дате отправления: