Michael Fuhr wrote:
> On Fri, Dec 02, 2005 at 04:30:54PM -0500, Tom Lane wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > Wow, check this out:
> > > test=> SELECT CAST (pow(10::numeric, 10000) + 1 AS TEXT)
> > > It works fine! I have all the digits, and the trailing 1.0:
> > > 000001.0000000000000000
> > > while SELECT pow(10::numeric, 10000) fails.
> >
> > That's just about as wacky as can be, because numeric_text() is
> > implemented on top of numeric_out() ... there's no way that numeric_out
> > can be delivering the wrong answer if the cast produces the right text.
> > So somewhere between numeric_out and the delivery to the client,
> > something's getting confused. I think it's time you got out your
> > debugger and started tracing through the backend ...
>
> Bruce, have you run a process trace on the backend to see if write()
> (or whatever) is writing the correct number of characters? What
> exactly is your output device and how are you connected to the
> machine that runs the backend (ssh to a remote box from an xterm,
> sitting in front of the box's VT52 serial console, etc.)?
>
> If you run the query that fails in a standalone backend, do you get
> something like "(typeid = 1700, len = -1, typmod = -1, byval = f)"
> at the end of the line, or is that part truncated too?
I found the cause. I traced into printf then realized I was not in libc
but port/snprintf.c, and I see 4096 defined for those buffers. I will
work on a patch to make it dynamic. At the time I think there was
thought that 4096 was as large as it ever needed to be, but obviously
this was wrong. I think Win32 would see the same failure because it used
port/snprintf.c too.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
