On 2014-05-23 10:01:37 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
The next question is whether to wait till after the branching with this?
+1 for waiting (it's only a couple weeks anyway). This isn't a
user-facing feature in any way, so I feel no urgency to ship it
On 2014-06-19 19:31:28 +0200, Andres Freund wrote:
On 2014-05-23 10:01:37 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
The next question is whether to wait till after the branching with this?
+1 for waiting (it's only a couple weeks anyway). This isn't a
Andres Freund and...@2ndquadrant.com writes:
Hm, that missed a couple things. Updated patch attached. Besides adding
the missed documentation adjustments this also removes the -A
commandline/startup packet parameter since it doesn't serve a purpose
anymore.
Does anyone think we should rather
On Thu, May 22, 2014 at 5:00 PM, Alvaro Herrera
alvhe...@2ndquadrant.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
On 2014-05-23 07:20:12 -0400, Robert Haas wrote:
On Thu, May 22, 2014 at 5:00 PM, Alvaro Herrera
alvhe...@2ndquadrant.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.
On Fri, May 23, 2014 at 8:15 AM, Andres Freund and...@2ndquadrant.com wrote:
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?
Robert Haas robertmh...@gmail.com writes:
On Fri, May 23, 2014 at 8:15 AM, Andres Freund and...@2ndquadrant.com wrote:
That means you're for a (differently named) disable macro? Or is it not
recent enough that you don't care?
I'm leaning toward thinking we should just rip it out. The fact
On 2014-05-23 09:56:03 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, May 23, 2014 at 8:15 AM, Andres Freund and...@2ndquadrant.com
wrote:
That means you're for a (differently named) disable macro? Or is it not
recent enough that you don't care?
I'm leaning
Andres Freund and...@2ndquadrant.com writes:
The next question is whether to wait till after the branching with this?
+1 for waiting (it's only a couple weeks anyway). This isn't a
user-facing feature in any way, so I feel no urgency to ship it in 9.4.
regards, tom lane
On Thu, May 22, 2014 at 4:31 PM, Andres Freund and...@2ndquadrant.com wrote:
Since there seem to be multiple static checkers (coverity, clang
checker) having problems with assert_enabled can we just optionally
disable it?
I am thinking of replacing it by a AssertionsEnabled() macro which then
Andres Freund and...@2ndquadrant.com writes:
Since there seem to be multiple static checkers (coverity, clang
checker) having problems with assert_enabled can we just optionally
disable it?
I am thinking of replacing it by a AssertionsEnabled() macro which then
is unconditionally defined when
On 2014-05-22 16:37:35 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Since there seem to be multiple static checkers (coverity, clang
checker) having problems with assert_enabled can we just optionally
disable it?
I am thinking of replacing it by a
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
13 matches
Mail list logo
