On 07.06.2013 19:33, Tom Lane wrote:
Heikki Linnakangas<hlinnakan...@vmware.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
