| От | Andreas Pflug |
|---|---|
| Тема | Re: [Slony1-general] Re: dangling lock information? |
| Дата | |
| Msg-id | 4314D14D.2070205@pse-consulting.de обсуждение исходный текст |
| Ответ на | Re: [Slony1-general] Re: dangling lock information? (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
| Список | pgsql-hackers |
Alvaro Herrera wrote: > >>Unfortunately, it's not at all obvious how to accomplish that :-(. > > > I don't think it can be easily done with the current code. This is > plpgsql code, right? There are some ways to cause recompilation for > those, at least on the 8.1 code I'm looking at. Well at least when a procedure is dropped, its cached plans could be dropped as well (apparently the cache plan is located trough some kind of hash, not the pg_proc.oid?). I do understand that the usual case, a table oid changed while cached inside a procedure isn't easily detectable because it would require dependency information generated from procedure's source. Regards, Andreas
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера