| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: WAL format and API changes (9.5) |
| Date: | 2014-04-03 23:40:28 |
| Message-ID: | 20140403234028.GI17307@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2014-04-03 19:33:12 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2014-04-03 19:08:27 -0400, Tom Lane wrote:
> >> A somewhat more relevant concern is where are we going to keep the state
> >> data involved in all this. Since this code is, by definition, going to be
> >> called in critical sections, any solution involving internal pallocs is
> >> right out.
>
> > We actually already allocate memory in XLogInsert() :(, although only in
> > the first XLogInsert() a backend does...
>
> Ouch. I wonder if we should put an Assert(not-in-critical-section)
> into MemoryContextAlloc.
XLogInsert() is using malloc() directly, so that wouldn't detect this
case...
It's not a bad idea tho. I wonder how far the regression tests
get...
Not even through initdb. GetVirtualXIDsDelayingChkpt() is to blame.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | YAMAMOTO Takashi | 2014-04-04 02:36:05 | Re: Securing "make check" (CVE-2014-0067) |
| Previous Message | Tom Lane | 2014-04-03 23:33:12 | Re: WAL format and API changes (9.5) |