Re: Commits 8de72b and 5457a1 (COPY FREEZE)
От | Andres Freund |
---|---|
Тема | Re: Commits 8de72b and 5457a1 (COPY FREEZE) |
Дата | |
Msg-id | 20121206141221.GA1000@alap2 обсуждение исходный текст |
Ответ на | Re: Commits 8de72b and 5457a1 (COPY FREEZE) (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Commits 8de72b and 5457a1 (COPY FREEZE)
|
Список | pgsql-hackers |
On 2012-12-06 14:07:32 +0000, Simon Riggs wrote: > 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. I remain unconvinced by that argument, but if I am alone with this ok. Could we at least make it a WARNING? Nobody ever reads NOTICEs because it contains so much noise. And this is isn't noise. Its a bug on the client side. Greetings, Andres Freund --Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: