Обсуждение: 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