Re: Commits 8de72b and 5457a1 (COPY FREEZE) - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Commits 8de72b and 5457a1 (COPY FREEZE)
Date
Msg-id CA+U5nMK+_Px8YZD7v49PLbzCUgx8Anw-ckoGghfB3H9XaqpSug@mail.gmail.com
Whole thread Raw
In response to Re: Commits 8de72b and 5457a1 (COPY FREEZE)  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Commits 8de72b and 5457a1 (COPY FREEZE)  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On 6 December 2012 13:12, Andres Freund <andres@2ndquadrant.com> wrote:
> Hi,
>
> On 2012-12-03 17:34:01 -0800, Jeff Davis wrote:
>> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8de72b66a2edcf12c812de0a73bd50b6b7d81d62
>
> On the subject of that patch. I am not a big fan of only emitting a NOTICE if
> FREEZE wasn't properly used:
>
> +       if (cstate->freeze && (hi_options & HEAP_INSERT_FROZEN) == 0)
> +               ereport(NOTICE,
> +                               (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> +                                errmsg("FREEZE option specified but pre-conditions not met")));
> +
>
> Imo it should fail. Imagine adding FREEZE to the loading part of your
> application and not noticing the optimization broke because somebody
> else changed something in another part of the loading procedure.
>
> Not sure whether that discussed previously.

It was. Only Robert and I spoke about that.

Also imagine having to analyze your code in detail to reevaluate the
exact optimisation required each time. This way you get to add FREEZE
and have it work always, with feedback if its not optimized.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Switching timeline over streaming replication
Next
From: Andres Freund
Date:
Subject: Re: Commits 8de72b and 5457a1 (COPY FREEZE)