Re: [GENERAL] Invalidation of cached plans for stored procedures ?
От | Adrian Klaver |
---|---|
Тема | Re: [GENERAL] Invalidation of cached plans for stored procedures ? |
Дата | |
Msg-id | 62bc7c80-22ce-58e4-1243-6d83f7385eda@aklaver.com обсуждение исходный текст |
Ответ на | [GENERAL] Invalidation of cached plans for stored procedures ? (Pierre Ducroquet <pierre.ducroquet@people-doc.com>) |
Список | pgsql-general |
On 06/21/2017 06:06 AM, Pierre Ducroquet wrote: Please reply to list also. Ccing list. > On Wednesday, June 21, 2017 5:49:29 AM CEST you wrote: >> On 06/21/2017 04:28 AM, Pierre Ducroquet wrote: >>> Hi >>> >>> >>> I found a workaround using event triggers to rewrite every function when >>> an >>> alter occurs on such a table, but this seems… odd to me. I don't think we >>> are doing anything very complicated here, so I'm surprised that nothing >>> has been done yet to fix that issue. >> >> https://www.postgresql.org/docs/9.6/static/plpgsql-statements.html#PLPGSQL-S >> TATEMENTS-EXECUTING-DYN >>> Did I miss something obvious, or should I report that as a bug and start >>> digging PostgreSQL code ? >> >> https://www.postgresql.org/docs/9.6/static/plpgsql-implementation.html#PLPGS >> QL-PLAN-CACHING >>> Thanks > > Hi Adrian > > I know this caching behavior is well-known and documented, and a disturbed way > of writing triggers will fix it (prefixing every statement with EXECUTE would > make for even uglier procedures), but still it seems counter-intuitive and > could deserve being called a bug, or a serious restriction. > I was very surprised to be hit by this so easily. Also, even after a backend > was hit by a failure, it kept running the wrong plan until I forced a new > function version. Hence my questioning, is there more than just «plpgsql cache > plans» in that issue… > If there is nothing else, then I'll start digging the code… I don't know, which is why I am returning this to list. > > Pierre > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: