Horton

Re: Patch: plan invalidation vs stored procedures

Hannu Krosing <hannu@2ndquadrant.com>

View thread View on postgr.es
From: Hannu Krosing <hannu@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, Dimitri Fontaine <dfontaine@hi-media.com>, Bruce Momjian <bruce@momjian.us>, Joshua Drake <jd@commandprompt.com>, Gregory Stark <stark@enterprisedb.com>, Asko Oja <ascoja@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, pgsql-hackers@postgresql.org, Andrew Dunstan <andrew@dunslane.net>, David Fetter <david@fetter.org>, Martin Pihlak <martin.pihlak@gmail.com>
Date: 2008-08-19T21:17:25Z
Lists: pgsql-hackers 
On Tue, 2008-08-19 at 16:56 -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > The actual criterion is not really "new user-visible feature" versus
> > "bug fix".  It's more an attempt at measuring how large a potential
> > impact the change has.  The patch I saw was introducing a whole new
> > message type to go through the shared invalidation queue, which is not
> > something to be taken lightly (consider that there are three message
> > types of messages currently.)
> 
> I hadn't read it yet, but that makes it wrong already.  There's no need
> for any new inval traffic --- the existing syscache inval messages on
> pg_proc entries should serve fine.

I have'nt looke at the patch either, but I suspect that what goes
through shared mem is the registration for invalidation, as dependent
function OIDs are only learned while compiling functions

so when f_caller() learns that it caches plan f_called() then it
registers through shared mem message its wish to invalidate this plan if
f_called() is dropped or redefined.

--------------
Hannu