Re: Hard limit on WAL space used (because PANIC sucks)
От | Heikki Linnakangas |
---|---|
Тема | Re: Hard limit on WAL space used (because PANIC sucks) |
Дата | |
Msg-id | 51B0A24B.2010006@vmware.com обсуждение исходный текст |
Ответ на | 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)
|
Список | pgsql-hackers |
On 06.06.2013 17:17, Andres Freund wrote: > On 2013-06-06 17:00:30 +0300, Heikki Linnakangas wrote: >> A more workable idea is to sprinkle checks in higher-level code, before you >> hold any critical locks, to check that there is enough preallocated WAL. >> Like, at the beginning of heap_insert, heap_update, etc., and all similar >> indexam entry points. I propose that we maintain a WAL reservation system in >> shared memory. > > I am rather doubtful that this won't end up with a bunch of complex code > that won't prevent the situation in all circumstances but which will > provide bugs/performance problems for some time. > Obviously that's just gut feeling since I haven't see the code... I also have a feeling that we'll likely miss some corner cases in the first cut, so that you can still run out of disk space if you try hard enough / are unlucky. But I think it would still be a big improvement if it only catches, say 90% of the cases. I think it can be made fairly robust otherwise, and the performance impact should be pretty easy to measure with e.g pgbench. - Heikki
В списке pgsql-hackers по дате отправления: