From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>, Peter Geoghegan <pg(at)heroku(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Hard limit on WAL space used (because PANIC sucks) |
Date: | 2013-06-06 14:52:59 |
Message-ID: | 51B0A24B.2010006@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2013-06-06 15:01:52 | Statement timeout logging |
Previous Message | Andres Freund | 2013-06-06 14:28:13 | Re: all_visible replay aborting due to uninitialized pages |