"Jon Erdman (aka StuckMojo)" <postgre...@thewickedtribe.net> writes:
> So, I still run 7.4.5 for my medical billing app, and in playing around with
> 8.5 at AustinPUG last week I discovered that if I try to restore one of my
> backups from 7.4 (produced with 7.4 pg_dump) into 8.5devel using 8.5
> pg_restore and -j 2, it immediately segfaults. 8.4 does as well.
Ouch.
> I built 8.5 with debug to get a bt and investigate what's going on, and I
> found that it's a dependency in the archive TOC that is much higher than the
> highest dump id in the TOC. This doesn't seem all that odd, considering the
> comment right above the offending block says there can be deps to things
> that aren't in the archive. This causes the code to index way off the end of
> the array of TOC entries by dumpId.
No, the problem is that back then the dependencies meant something
completely different; they were object OIDs not dump ID numbers.
I think what we have to do is forbid -j restores from archives older
than archive version 1.8 (ie, pg_dump 8.0). It doesn't seem worth it
to try to support parallel restore from nearly-obsolete versions, and
I suspect that we couldn't do it even if we tried --- the reason the
representation got changed is that the old way simply didn't work for
any significant use of the dependency info. Just ignoring the
dependencies, as your patch effectively proposes, is going to lead to
restore failures or worse.
It seems like a good idea to put a range check into that loop as well,
but I think it should throw error not silently ignore bad data ...
Thanks for the report!
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
