> I have repaired the most recently introduced coredump in pg_dump,
> but it still crashes on the regression test database.
>
> Issue 1:
>
> The "most recently introduced coredump" came from the change to
> oidvector/int2vector to suppress trailing zeroes in the output
> routine. pg_dump was assuming that it would see exactly the
> right number of zeroes, and wasn't bothering to initialize any
> leftover array locations --- but it would happily try to dereference
> those locations later on. Ugh.
>
> Although cleaning up pg_dump's code is clearly good practice, maybe
> this should raise a flag about whether suppressing the zeroes is
> a good idea. Are there any client applications that will break
> because of this change? I'm not sure...
I think we are OK. There are very few places the vectors are used.
They really weren't used even as part of initdb except to define the
types. Makes sense pg_dump uses it, I guess, but I can't imagine other
apps using it. With a definable length, I think we have to supress the
zero padding.
> I am inclined to go ahead and insert vsnprintf into libpq.
> The risk of problems seems pretty small (and it's zero on any
> machine with a reasonably recent libc, since then vsnprintf
> will be in libc and we won't link our version). The risk of
> missing a buffer-overrun condition in pg_dump, and shipping
> a pg_dump that will fail on someone's database, seems worse.
You bring up an interesting point. I say just link it in and see what
happens. No real good way to know how much memory sprintf needs.
-- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026