Re: Hard limit on WAL space used (because PANIC sucks)

On 07.06.2013 19:33, Tom Lane wrote:
> Heikki Linnakangas<hlinnakangas(at)vmware(dot)com> writes:
>> On 06.06.2013 17:00, 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.
>
>> Actually, there's one place that catches most of these: LockBuffer(...,
>> BUFFER_LOCK_EXCLUSIVE). In all heap and index operations, you always
>> grab an exclusive lock on a page first, before entering the critical
>> section where you call XLogInsert.
>
> Not only is that a horrible layering/modularity violation, but surely
> LockBuffer can have no idea how much WAL space will be needed.

It can be just a conservative guess, like, 32KB. That should be enough
for almost all WAL-logged operations. The only exception that comes to
mind is a commit record, which can be arbitrarily large, when you have a
lot of subtransactions or dropped/created relations.

- Heikki