Re: NOTICES about portals
От | Tom Lane |
---|---|
Тема | Re: NOTICES about portals |
Дата | |
Msg-id | 11192.961716615@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: NOTICES about portals (Brook Milligan <brook@biology.nmsu.edu>) |
Список | pgsql-hackers |
Brook Milligan <brook@biology.nmsu.edu> writes: > Well, I'm working on it. I now have something in psql that emits this > NOTICE:. Things like the following do it at the time of commiting the > transaction: > begin; > declare mycursor cursor for select * from some_view; > fetch 10 in mycursor; > end; > The catch is that it doesn't happen with all views. I'm trying to > figure out what types of views it does happen on, though. Hmm. I seem to recall something about a bug with cursors on views, but can't find anything about it in the CVS logs for the likely files. I do see a post-7.0 bug fix for the case of redeclaring a cursor name within a transaction: if you dobegin;declare foo cursor for ...;declare foo cursor for ...;... things will act very peculiar. That's probably unrelated to your problem, but I wanted to raise a flag for you that the behavior you're trying to chase may have more to do with a pattern of cursor declarations/uses than with the exact details of the query. Also, if you haven't already done so, I'd recommend building the backend with --enable-cassert and compiling backend/utils/mmgr/aset.c with -DCLOBBER_FREED_MEMORY. If it's something like a reference to already-freed memory, these will make the failure a lot more reproducible. regards, tom lane
В списке pgsql-hackers по дате отправления: