Oversize proc sources (was Re: [BUGS] Backend dies creating plpgsql procedures (with reproducible example!))

Wayne Piekarski <wayne(at)senet(dot)com(dot)au> writes:
> the other day I did a pg_dump of our 6.4.2 database and tried to load it
> back into 6.5 - it failed with the error message:

> FATAL 1: btree: failed to add item to the page

IIRC this just means the tuple is too long ... btrees want to be able to
fit at least two tuples per disk page, so indexed fields can't exceed
4k bytes in a stock installation. Sometimes you'll get away with more,
but not if two such keys end up on the same btree page.

It's not real clear to me *why* we are keeping an index on the prosrc
field of pg_proc, but we evidently are, so plpgsql source code can't
safely exceed 4k per proc as things stand.

In short, it was only by chance that you were able to put this set of
procs into 6.4 in the first place :-(

Can any hackers comment on whether pg_proc_prosrc_index is really
necessary?? Just dropping it would allow plpgsql sources to approach 8k,
and I can't think of any scenario where it's needed...

BTW, Jan has been muttering about compressing plpgsql source, which
would provide some more breathing room for big procs, but not before 6.6.

regards, tom lane