From 767fc1c520a19f353006a5926cfea63bc4a4a57b Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Thu, 3 Apr 2014 15:09:37 +0300 Subject: Avoid palloc in critical section in GiST WAL-logging. Memory allocation can fail if you run out of memory, and inside a critical section that will lead to a PANIC. Use conservatively-sized arrays in stack instead. There was previously no explicit limit on the number of pages a GiST split can produce, it was only limited by the number of LWLocks that can be held simultaneously (100 at the moment). This patch adds an explicit limit of 75 pages. That should be plenty, a typical split shouldn't produce more than 2-3 page halves. The bug has been there forever, but only backpatch down to 9.1. The code was changed significantly in 9.1, and it doesn't seem worth the risk or trouble to adapt this for 9.0 and 8.4. --- src/backend/access/gist/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'src/backend/access/gist/README') diff --git a/src/backend/access/gist/README b/src/backend/access/gist/README index 4bcac1f2c79..dd4c9fa70a0 100644 --- a/src/backend/access/gist/README +++ b/src/backend/access/gist/README @@ -135,7 +135,7 @@ that didn't need to be split. This differs from the insertion algorithm in the original paper. In the original paper, you first walk down the tree until you reach a leaf page, and -then you adjust the downlink in the parent, and propagating the adjustment up, +then you adjust the downlink in the parent, and propagate the adjustment up, all the way up to the root in the worst case. But we adjust the downlinks to cover the new key already when we walk down, so that when we reach the leaf page, we don't need to update the parents anymore, except to insert the -- cgit v1.2.3