From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brook Milligan <brook(at)biology(dot)nmsu(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: NOTICES about portals |
Date: | 2000-06-22 23:30:15 |
Message-ID: | 11192.961716615@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Brook Milligan <brook(at)biology(dot)nmsu(dot)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 do
begin;
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
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2000-06-22 23:35:12 | RE: Big 7.1 open items |
Previous Message | Brook Milligan | 2000-06-22 23:12:23 | Re: NOTICES about portals |