| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: -DDISABLE_ENABLE_ASSERT |
| Date: | 2014-05-23 12:15:47 |
| Message-ID: | 20140523121547.GG31579@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2014-05-23 07:20:12 -0400, Robert Haas wrote:
> On Thu, May 22, 2014 at 5:00 PM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
> > Andres Freund wrote:
> >> On 2014-05-22 16:37:35 -0400, Tom Lane wrote:
> >> > We could do that ... but I wonder if we shouldn't remove assert_enabled
> >> > altogether. What's the use case for turning it off? Not matching the
> >> > speed of a non-cassert build, because for instance MEMORY_CONTEXT_CHECKING
> >> > doesn't get turned off.
> >>
> >> I've used it once or twice to avoid having to recompile postgres when I
> >> wanted things not to be *that* slow (AtEOXactBuffers() I am looking at
> >> you). But I wouldn't be very sad if it'd go.
> >>
> >> Anybody against that?
> >
> > I have used it too (for a different reason IIRC), but like you I
> > wouldn't have a problem if it weren't there.
>
> I've used it, too, although not recently.
That means you're for a (differently named) disable macro? Or is it not
recent enough that you don't care?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-05-23 12:38:16 | Re: HEAD crashes with assertion and LWLOCK_STATS enabled |
| Previous Message | David Rowley | 2014-05-23 11:45:09 | Re: Allowing join removals for more join types |