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

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

Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> 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,

... uh, isn't that a bug to be fixed?

> 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.

Yeah, I realized we'd have to do something about elog's own allocations.
Not sure if a blanket exemption for ErrorContext is the best way. I'd
been thinking of having a way to turn off the complaint once processing
of an elog(PANIC) has started.

> I didn't backpatch this.

Agreed.

BTW, I'm pretty sure you added some redundant assertions in mcxt.c.
eg, palloc does not need its own copy.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-04-04 14:01:13 Re: GiST support for inet datatypes
Previous Message Tom Lane 2014-04-04 13:50:14 Re: Securing "make check" (CVE-2014-0067)