Thread: NOTICES about portals
Can anyone explain the meaning of the following NOTICE: NOTICE: trying to delete portal name that does not exist. I get these regularly when using pgaccess to view views. Pgaccess makes no direct use of portals (and I can't find any docs on them) so I'm lost. It doesn't seem to be a problem with psql on the same views. Does this indicate a bug in the backend code somewhere? Thanks for your help. Cheers, Brook
Brook Milligan <brook@biology.nmsu.edu> writes: > Can anyone explain the meaning of the following NOTICE: > NOTICE: trying to delete portal name that does not exist. > Does this indicate a bug in the backend code somewhere? Probably. Can you exhibit a command sequence that causes it? (You might try turning on a higher debug level to get the backend to log the commands pgaccess sends...) BTW, what version are you running? I have a vague recollection of having fixed something in that area recently, but it might be post-7.0. regards, tom lane
Brook Milligan <brook@biology.nmsu.edu> writes: > Can anyone explain the meaning of the following NOTICE: > NOTICE: trying to delete portal name that does not exist. > Does this indicate a bug in the backend code somewhere? Probably. Can you exhibit a command sequence that causes it? (You might try turning on a higher debug level to get thebackend to log the commands pgaccess sends...) 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. So far, it looks like views of one table or views of a join between 2 tables are fine; whereas views of a join between a table and view might trigger the NOTICE. Unfortunately, this is all in the context of a rather complex database. I'm still trying to extract a sufficient and simple example. Hopefully, this information may trigger some ideas in the meantime. BTW, what version are you running? I have a vague recollection of having fixed something in that area recently, but itmight be post-7.0. I'm running 7.0. Thanks for the help. Cheers, Brook
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