From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] pg_dump not in very good shape |
Date: | 2000-01-16 05:36:21 |
Message-ID: | 200001160536.AAA08522@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2000-01-16 05:39:53 | Re: [HACKERS] I think we need an explicit parsetree node for CAST |
Previous Message | Tom Lane | 2000-01-16 04:51:59 | Re: [HACKERS] INDEX_MAX_KEYS and pg_dump |