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  (Tom Lane <tgl@sss.pgh.pa.us>)
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:

Previous
From: Andrew Gierth
Date:
Subject: Re: Replay attack of query cancel
Next
From: Alvaro Herrera
Date:
Subject: Re: Replay attack of query cancel