| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Andres Freund <andres(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 11:20:12 |
| Message-ID: | CA+TgmoaSPGaawEP8LvGuVYEj_4MXXvj_qcd_yAVUz73qgfwMXw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-05-23 11:26:17 | Re: SKIP LOCKED DATA (work in progress) |
| Previous Message | Sandro Santilli | 2014-05-23 11:09:07 | postgres_fdw and connection management |