Re: Patch: plan invalidation vs stored procedures - Mailing list pgsql-hackers
From | Asko Oja |
---|---|
Subject | Re: Patch: plan invalidation vs stored procedures |
Date | |
Msg-id | ecd779860808161302h5aac673ch5265408a321353d6@mail.gmail.com Whole thread Raw |
In response to | Re: Patch: plan invalidation vs stored procedures (Martin Pihlak <martin.pihlak@gmail.com>) |
Responses |
Re: Patch: plan invalidation vs stored procedures
|
List | pgsql-hackers |
<div dir="ltr">Hi<br /><br />We need plan invalidation fix in 8.3 also at least it would make migrating from 8.2 to 8.3 muchmore attractive. <br />Currenlty we are having problems related to plan invalidation couple of times per week (mainlywe have to let developers change their code before we release it into live databases but it feels like sitting onticking bomb after previous downtime). <br /> Is it possible to get it into some official 8.3.x release or should we doit in house? <br /><div class="gmail_quote">Who should add it into september commitfest?<br /><br />Asko<br /><br /><br/>On Fri, Aug 15, 2008 at 2:13 PM, Martin Pihlak <span dir="ltr"><<a href="mailto:martin.pihlak@gmail.com">martin.pihlak@gmail.com</a>></span>wrote:<br /><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">Tom Lanewrote:<br /> > Martin Pihlak <<a href="mailto:martin.pihlak@gmail.com">martin.pihlak@gmail.com</a>> writes:<br/> >> Changing statement result type is also currently prohibited in<br /> >> StorePreparedStatement.There maybe good reasons for this,<br /> ><br /> > How about "the SQL spec says so"?<br /> ><br/> > Admittedly, it's a bit of a jump from views to prepared statements,<br /> > but the spec is perfectly clearthat altering a table doesn't alter<br /> > any views dependent on it: SQL99 11.11 <add column definition>saith<br /><br /></div>As you said it is a bit of a jump ... For one thing view definitions are<br /> persistentwhereas statements are bound to be replanned sooner or later -<br /> reconnects etc. Disallowing replanning afterinvalidation just postpones<br /> it and meanwhile the cached plans are left unusable ("cached plan must not<br /> changeresult"). IMHO the problem should be left for the application to handle.<br /> Because this is where it will end upanyway.<br /><br /> Attached is a patch that implements plan invalidation on function DROP,<br /> REPLACE and ALTER. Functionoids used by the query are collected in analyze phase<br /> and stored in PlannedStmt. Only plans that referencethe altered function are<br /> invalidated. The patch also enables replanning on result set change.<br /><br />regards,<br /><font color="#888888">Martin<br /><br /></font><br /><br /> --<br /> Sent via pgsql-hackers mailing list(<a href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br /> To make changes to your subscription:<br/><a href="http://www.postgresql.org/mailpref/pgsql-hackers" target="_blank">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/><br /></blockquote></div><br /></div>
pgsql-hackers by date: