Re: [HACKERS] pg_dump not in very good shape

> 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