Re: Patch: plan invalidation vs stored procedures

Поиск
Список
Период
Сортировка
От Asko Oja
Тема Re: Patch: plan invalidation vs stored procedures
Дата
Msg-id ecd779860808161302h5aac673ch5265408a321353d6@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Patch: plan invalidation vs stored procedures  (Martin Pihlak <martin.pihlak@gmail.com>)
Ответы Re: Patch: plan invalidation vs stored procedures  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Gierth
Дата:
Сообщение: Re: Replay attack of query cancel
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Replay attack of query cancel