I wrote: > It's fairly easy to reproduce in the regression database: > type "\d ten<TAB>". I'm not sure what the triggering condition > is exactly, because some seemingly-similar cases don't fail, > for instance "\d test<TAB>" works as expected, ditto "\d t<TAB>".
It turns out that the problem occurs when there are exactly 9 + 10*N possible completions, for any N>=0. There's an off-by-one logic bug in libedit that results in a memory stomp because it forgets to enlarge an array before storing a terminating null pointer in it. The upstream netbsd sources incorporated a fix some time ago: http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/readline.c.diff?r1=1.82&r2=1.83&sortby=date&f=h with credit to Caleb Welton at Greenplum --- I wonder if he found it because of psql failing? Apple hasn't incorporated this fix as of OS X 10.6.3, however. What's slightly more distressing is that the same source file (readline.c) appears to have at least two other occurrences of the same broken array-enlargement coding pattern, which were *not* fixed. I've reported this to Apple but I'm not real sure where to file NetBSD bugs. Anybody want to yank the BSD guys' chain about the other errors? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
