Allocations in critical section (was Re: WAL format and API changes (9.5))

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Allocations in critical section (was Re: WAL format and API changes (9.5))
Date: 2014-04-04 11:31:48
Message-ID: 533E9824.9020604@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ok, I fixed the issues that the assertion fixed. I also committed a
patch to add the assertion itself; let's see if the buildfarm finds more
cases that violate the rule.

It ignores the checkpointer, because it's known to violate the rule, and
allocations in ErrorContext, which is used during error recovery, e.g if
you indeed PANIC while in a critical section for some other reason.

I didn't backpatch this. Although you shouldn't be running with
assertions enabled in production, it nevertheless seems too risky. There
might be some obscure cases where there is no real risk, e.g because the
current memory context always has enough free space because of a
previous pfree, and it doesn't seem worth tracking down and fixing such
issues in backbranches. You have to be pretty unlucky to run out of
memory in a critical section to begin with.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rohit Goyal 2014-04-04 11:53:05 HOT Update || want to use a different page for updated tuple
Previous Message Andres Freund 2014-04-04 11:13:45 Re: [PATCH] Negative Transition Aggregate Functions (WIP)