Andres Freund 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 keep -A and have i
On 2014-06-19 19:31:28 +0200, Andres Freund wrote:
> On 2014-05-23 10:01:37 -0400, Tom Lane wrote:
> > Andres Freund 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 featu
On 2014-05-23 10:01:37 -0400, Tom Lane wrote:
> Andres Freund 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.
Here's
Andres Freund 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
--
Sent via pgsql-
On 2014-05-23 09:56:03 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, May 23, 2014 at 8:15 AM, Andres Freund
> > 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
Robert Haas writes:
> On Fri, May 23, 2014 at 8:15 AM, Andres Freund 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 that
> 3 out of the 4 people commenting
On Fri, May 23, 2014 at 8:15 AM, Andres Freund 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?
>> >
On 2014-05-23 07:20:12 -0400, Robert Haas wrote:
> On Thu, May 22, 2014 at 5:00 PM, Alvaro Herrera
> 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
On Thu, May 22, 2014 at 5:00 PM, Alvaro Herrera
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 no
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
On 2014-05-22 16:37:35 -0400, Tom Lane wrote:
> Andres Freund 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
On Thu, May 22, 2014 at 4:31 PM, Andres Freund 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
> is unconditionall
Andres Freund 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 DISABLE_ENABLE_AS
13 matches
Mail list logo
