> > My best guess is there's a bug in exec_assign_value in that it
> > doesn't handle assigning to PLPGSQL_DTYPE_ROW... but I'm not
> > seeing anything in the error logs and there aren't any errors
> > being thrown.
>
> Can you give us a test case now that you understand the issue
> better?
Sweet! Yes! :-] Only took me forever and a day to get it down small
enough without cutting too much. ::sigh:: What a relief. Alright, my
best guess is that this is a memory problem. If you remove column w
from the table s.c, everything works with ROWTYPE. Why that would
affect this, I have no clue, but it does. Use a RECORD type, and
you're good to go. ::shrug:: Anyway, I've attached the test case.
Change to type RECORD if you'd like to verify that things work.
Please feel free to ask questions. -sc
#### ORIGINAL EMAIL before test case ####
Unfortunately no. I'm working on trimming away at this package's
schema to try and get to the lowest common denominator... and haven't
been able to come up with anything conclusive. I got it down to less
than 200 lines, then when I went to trim a little more, I went too far
in my cutting and the backend did the right thing. What's worse, is I
cut an adjacent table that had nothing to do with the table/procedure
in question. Anyway, when I went to use my ~ backup file, the backup
file was nearly from the start back at nearly 30K lines. ::sigh::
Working from the ground up wasn't yielding any useful results either.
:( I'm going to take another shot at it later and manually make
backups, but I've blown my whole day trying to track this down one way
or another and need to finish up some other things 1st.
I fired up gdb though and have traced through the execution of the
backend and have been able to generate two different execution paths
for a RECORD and ROWTYPE. I went through and read the two paths side
by side, but I don't understand enough of the backend to be able to
use the information in the structures effectively. My biggest problem
is I don't know what data/variables I should be watching out for and
what's superfluous. In my simplified test case, things work
correctly. When I use my regression tests + ROWTYPE, things bomb
miserably. If I use RECORD and I'm just fine.
Tom, maybe you have some advice with regards to what I can look for.
The select statement is returning the right data, that much I can
verify with gdb. What I'm lost on is figuring out where the value for
the datum is stored. I'm wondering if this isn't a BIGINT issue, but
like I said, I haven't been able to reproduce this problem with a
BIGINT data type in my tables. Because of that inability to reproduce
this on a smaller scale, I'm worried it's a memory management problem.
Internally, the attype is correctly listed as 20 in all of the
structures, from what I've observed... but somewhere along the way,
the datum is being returned as NULL in the case of a ROWTYPE and not a
RECORD.
Any other ideas? -sc
--
Sean Chittenden
