Re: NOTICES about portals - Mailing list pgsql-hackers

From Tom Lane
Subject Re: NOTICES about portals
Date
Msg-id 11192.961716615@sss.pgh.pa.us
Whole thread Raw
In response to Re: NOTICES about portals  (Brook Milligan <brook@biology.nmsu.edu>)
List 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 by date:

Previous
From: Brook Milligan
Date:
Subject: Re: NOTICES about portals
Next
From: "Hiroshi Inoue"
Date:
Subject: RE: Big 7.1 open items